Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Giofelix/Proyecto-automatizacion-Empresa/llms.txt

Use this file to discover all available pages before exploring further.

El pipeline de Jenkins de automation-arqc automatiza por completo la ejecución de la suite E2E de Playwright: desde la limpieza del workspace hasta la generación del reporte Allure y el archivo de artefactos. Soporta dos modos de operación (Libre y Despliegue), detecta cambios de forma inteligente en push automáticos y gestiona credenciales por entidad con fallback seguro — todo sin necesidad de intervención manual en el agente.

Configuración global

La configuración base del pipeline se define en el bloque superior del Jenkinsfile y aplica a todas las ejecuciones independientemente del modo.
PropiedadValor
Agenteautomatico_196
Herramienta Nodenode20
Timeout máximo90 minutos
Builds conservadosúltimos 20
Artefactos conservadosúltimos 10 builds
Cache de navegadores/home/ubuntu/.cache/playwright-browsers
Variable CItrue
El timeout de 90 minutos está calibrado para soportar ejecuciones en Modo Despliegue con múltiples entidades; las ejecuciones normales en integration terminan bastante antes.

Etapas del pipeline

1

Limpiar Workspace

Invoca cleanWs() para eliminar todos los archivos y artefactos que hayan quedado de builds anteriores en el agente. Esto garantiza que cada ejecución parte de un estado limpio y que no haya contaminación cruzada entre builds.
stage('Limpiar Workspace') {
    steps {
        cleanWs()
    }
}
2

Checkout SCM

Clona la rama que disparó el pipeline usando checkout scm. El checkout predeterminado está deshabilitado (skipDefaultCheckout(true)) para que este stage controle explícitamente cuándo se hace la clonación — siempre después de limpiar el workspace.
stage('Checkout SCM') {
    steps {
        checkout scm
    }
}
3

🔍 Información del Build

Inspecciona las causas del build (getBuildCauses()) para determinar si el disparador fue manual (un usuario en la UI) o automático (un push). Con esa información establece tres variables de entorno clave:
VariableDescripción
IS_MANUAL_BUILDtrue si fue lanzado por un usuario, false si fue por push
IS_MASTERtrue si la rama activa es master
PIPELINE_MODEDEPLOYMENT si se recibieron PROJECT_NAME + ENTITIES; FREE en caso contrario
En Modo Despliegue el nombre y la descripción del build se actualizan automáticamente al formato {VERSION} | {PROJECT_NAME} | {ENTIDADES} para identificarlo fácilmente en el historial de Jenkins. Luego imprime en consola un bloque de diagnóstico con todos los parámetros activos.
4

🔒 Control de Rama

Actúa como guardián para la rama master: si el pipeline corre en master pero el modo detectado es FREE (faltan ENTITIES y/o PROJECT_NAME), el build se marca inmediatamente como NOT_BUILT y ningún stage posterior se ejecuta.
stage('🔒 Control de Rama') {
    steps {
        script {
            if (env.IS_MASTER == 'true' && env.PIPELINE_MODE == 'FREE') {
                currentBuild.result = 'NOT_BUILT'
                currentBuild.description = '⏭ master: faltan ENTITIES/PROJECT_NAME'
            }
        }
    }
}
Este comportamiento es intencional: master representa producción y solo debe ejecutarse con un despliegue real identificado. Ver Modos de ejecución para más detalles.
5

✅ Validación Modo Despliegue

Solo se activa cuando el modo es DEPLOYMENT. Valida que cada microservicio especificado en PROJECT_NAME exista en getMicroservicioToTagMap() y que cada entidad de ENTITIES figure en getEntidadesValidas(). Si alguna validación falla, el pipeline lanza un error inmediatamente con la lista de problemas encontrados.Si la validación es exitosa, almacena los tags de módulo resueltos en RESOLVED_MODULE_TAGS y las entidades normalizadas en RESOLVED_ENTITIES como variables de entorno para los stages posteriores.
stage('✅ Validación Modo Despliegue') {
    when {
        allOf {
            expression { currentBuild.result != 'NOT_BUILT' }
            expression { env.PIPELINE_MODE == 'DEPLOYMENT' }
        }
    }
    steps {
        script {
            def validation = validateDeploymentParams()
            if (!validation.valid) {
                error "❌ Validación fallida:\n${validation.errors.join('\n  • ')}"
            }
            env.RESOLVED_MODULE_TAGS = validation.moduleTags.join(',')
            env.RESOLVED_ENTITIES = validation.entities.join(',')
        }
    }
}
6

🧐 Detección de Cambios

Este stage solo se activa cuando el build es automático (push), el modo es FREE y FORCE_FULL_SUITE está desactivado. Primero revisa si el mensaje del commit contiene [ci skip] o [skip ci] — si lo hace, el build se marca NOT_BUILT sin correr ninguna prueba.Si no hay skip, llama a analyzeChanges() para clasificar los archivos modificados en tres categorías:
ResultadoCondiciónEfecto
RUN_ALLCambios en playwright/, pages/login/, pages/common/, fixtures/index.js, fixtures/auth.fixture.js, suites/config-ambientes/, package.json, package-lock.jsonEjecuta la suite completa
RUN_TARGETCambios en pages/modulos/<modulo>/, suites/<Modulo>/, o specs específicosEjecuta solo el módulo o spec afectado
SKIPSolo cambios en archivos ignorados: .md, .gitignore, Jenkinsfile, specs/, docs/Marca el build como NOT_BUILT
7

📦 Instalación de Dependencias

Verifica las versiones de Node y npm, luego ejecuta npm ci para una instalación completamente reproducible desde package-lock.json. Si este stage falla, el pipeline imprime un diagnóstico con las causas más comunes.
node --version && npm --version
npm ci
Si falla, las causas más habituales son:
  • package-lock.json desactualizado o corrupto
  • Sin acceso a registry.npmjs.org desde el agente
  • Versión de Node incompatible con la declarada en package.json
8

🌐 Preparación de Navegadores

Verifica si existe el directorio de caché en /home/ubuntu/.cache/playwright-browsers. Si no existe, lo crea. Luego instala el binario de Chromium con npx playwright install chromium. En la mayoría de ejecuciones la descarga se salta porque el binario ya está en caché.
if [ ! -d "$PLAYWRIGHT_BROWSERS_PATH" ]; then
    mkdir -p "$PLAYWRIGHT_BROWSERS_PATH"
fi
npx playwright install chromium
9

🚀 Ejecución Modo Despliegue

Solo se activa cuando el modo es DEPLOYMENT. Itera sobre las entidades resueltas según el valor de EXECUTION_MODE:
  • per_entity — ejecuta una corrida de Playwright independiente por cada entidad. Por cada una: construye la URL base como http://172.17.1.214:9080/{entidad}/, resuelve credenciales con resolveCredentialIds() (específicas por entidad o genéricas), construye un patrón grep compuesto (módulo + entidad + tipo de prueba) y guarda los resultados Allure en un subdirectorio propio. Si alguna entidad falla, el pipeline continúa con las demás y al final lanza un error con el resumen de fallos.
  • all_entities_together — incluye todas las entidades como filtros OR en un único patrón grep junto con @todas_entidades, y usa credenciales genéricas directamente.
Los resultados Allure de cada entidad se copian a allure-results/ para el reporte unificado final.
10

🎯 Resolución de Filtros

Solo se activa en Modo Libre. Construye el patrón --grep que se pasará a Playwright según la combinación de parámetros activos. En builds manuales o con FORCE_FULL_SUITE, usa los parámetros del formulario (TEST_SUITE, MODULE, EXTRA_GREP). En builds automáticos usa la decisión tomada por analyzeChanges().
TEST_SUITEPatrón grep generado
smoke(?=.*@smoke)
regression(?=.*@regression|@smoke|@critical)
all(sin filtro — todas las pruebas)
autoResuelve a all en la rama integration
Si se especifica MODULE, añade (?=.*@{modulo}) al patrón. Si se especifica EXTRA_GREP, también se incluye como lookahead adicional.
11

🚀 Ejecución de Pruebas

Solo se activa en Modo Libre. Inyecta las credenciales USER_GENERIC y PASSWORD_UNIVERSAL desde el almacén de Jenkins y ejecuta Playwright con el patrón grep y las rutas de specs resueltos en el stage anterior:
LANG=es_ES.UTF-8 LANGUAGE=es_ES:es LC_ALL=es_ES.UTF-8 \
npx playwright test [spec_paths] [--grep 'patron']
Si el stage falla, el bloque post { failure } imprime un diagnóstico con pasos para investigar: revisar el reporte Allure, descargar test-results.zip e inspeccionar traces con npx playwright show-trace.

Post-acciones

El bloque post del pipeline se ejecuta siempre al final, independientemente del resultado.
BloqueCuándo se activaQué hace
alwaysSiempreGenera el reporte Allure desde allure-results/, archiva playwright-report/** y test-results/** (ambos con allowEmptyArchive: true), imprime la duración total del build
successBuild exitosoSi el resultado es NOT_BUILT imprime un mensaje de “sin ejecución de pruebas”; si hay pruebas exitosas muestra el número de build y la ruta al reporte Allure
failureBuild fallidoImprime un bloque de diagnóstico con pasos para investigar: reporte Allure, descarga de test-results.zip, inspección de traces con npx playwright show-trace
unstableBuild inestableImprime una advertencia indicando que algunas pruebas fallaron pero el pipeline completó
Si el mensaje del commit contiene [ci skip] o [skip ci] (sin distinción de mayúsculas), el stage 🧐 Detección de Cambios interrumpe el build marcándolo como NOT_BUILT. Esto evita consumir tiempo de agente en cambios que no requieren pruebas, como actualizaciones de documentación o ajustes al Jenkinsfile.

Modos de ejecución

Cómo configurar y diferenciar el Modo Libre y el Modo Despliegue, con todos sus parámetros y comportamientos.

Credenciales

Cómo registrar y gestionar las credenciales de Jenkins para automation-arqc, incluyendo el mecanismo de fallback por entidad.

Build docs developers (and LLMs) love