Fase 6.2
Jenkinsfile

Pipeline Setup · Jenkinsfile

El pipeline declarativo que Jenkins ejecuta en cada push al repositorio. Cuatro stages validan YAML, Ansible, OpenTofu y manifiestos de Kubernetes. Si algo falla, n8n recibe una notificacion para procesarla con LLM.

01

Los Cuatro Stages

Cada stage valida una parte distinta del proyecto. Si un stage falla, el pipeline se detiene inmediatamente y ejecuta el bloque post para notificar a n8n.

Lint YAMLyamllint
Valida la sintaxis de todos los archivos YAML en k3s/manifests/. Detecta errores de indentacion, duplicados y valores invalidos antes del deploy.
El pipeline se detiene. n8n recibe una notificacion de fallo.
Lint Ansibleansible-lint
Ejecuta ansible-lint sobre el directorio ansible/. Verifica que los playbooks y roles sigan las mejores practicas de Ansible.
El pipeline se detiene. Se reporta el archivo y la linea del error.
Validate OpenTofutofu validate
Ejecuta tofu validate en tofu/local/. Verifica que la sintaxis HCL sea correcta y que las referencias entre recursos sean validas.
El pipeline se detiene. OpenTofu reporta el error de sintaxis.
Validate K8s Manifestskubectl --dry-run
Ejecuta kubectl apply --dry-run=client sobre k3s/manifests/. Verifica que los manifiestos sean validos sin aplicarlos al cluster.
El pipeline se detiene. kubectl reporta el recurso y el campo invalido.
02

El Jenkinsfile Completo

El archivo Jenkinsfile en la raiz del repositorio define todo el pipeline. Cada stage usa container('tools') para ejecutarse dentro del contenedor del agente Kubernetes.

Jenkinsfile
pipeline {
    agent {
        kubernetes {
            yaml """
                apiVersion: v1
                kind: Pod
                spec:
                  containers:
                  - name: tools
                    image: alpine/k8s:1.29.2
                    command: [cat]
                    tty: true
            """
        }
    }
    stages {
        stage("Lint YAML") {
            steps { container("tools") { sh "yamllint k3s/manifests/" } }
        }
        stage("Lint Ansible") {
            steps { container("tools") { sh "ansible-lint ansible/" } }
        }
        stage("Validate OpenTofu") {
            steps { container("tools") { sh "tofu validate tofu/" } }
        }
        stage("Validate K8s Manifests") {
            steps { container("tools") { sh "kubectl --dry-run=client apply -f k3s/manifests/" } }
        }
    }
}
03

Notificacion de Fallos a n8n

El bloque post con la condicion failure se ejecuta solo si el pipeline falla. Envia un webhook a n8n con los detalles del build fallido. n8n puede procesar este evento con LLM y notificar a Discord.

Jenkinsfile — post block
post {
    failure {
        sh """
            curl -X POST http://n8n.aiops.svc.cluster.local:5678/webhook/jenkins-failure \\
              -H "Content-Type: application/json" \\
              -d '{"build": "${BUILD_NUMBER}", "job": "${JOB_NAME}"}'
        """
    }
}

Las variables BUILD_NUMBER, JOB_NAME, BUILD_DURATION y BUILD_URL son variables de entorno que Jenkins inyecta automaticamente en cada build. El webhook de n8n recibe estos datos y puede decidir si notificar a Discord, abrir un issue en GitHub o simplemente registrar el evento.

Siguiente: Jenkins vs GitHub Actions

La ultima pagina de la Fase 6 compara los dos enfoques de CI/CD y explica por que este proyecto cubre ambos deliberadamente.

Jenkins vs Actions