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.

En entornos de CI, las credenciales de automation-arqc nunca se almacenan en archivos .env ni en ningún otro fichero del repositorio. En su lugar, el pipeline las inyecta en tiempo de ejecución desde el almacén seguro de credenciales de Jenkins mediante withCredentials([...]). Esto aplica tanto al Modo Libre como al Modo Despliegue — en ambos casos las variables de entorno USER_GENERIC y PASSWORD_UNIVERSAL llegan al proceso de Playwright sin exponerse en los logs ni en el workspace.

Credenciales requeridas

Las siguientes credenciales deben existir en Jenkins. Las dos primeras son obligatorias siempre; las de entidad son opcionales y se usan cuando existen credenciales específicas para una entidad concreta.
Credential IDVariable de entornoUso
USER_GENERICUSER_GENERICUsuario genérico (fallback para todas las entidades)
PASSWORD_UNIVERSALPASSWORD_UNIVERSALContraseña genérica (fallback para todas las entidades)
<ENTIDAD>_USERUSER_GENERICUsuario específico por entidad (opcional)
<ENTIDAD>_PASSPASSWORD_UNIVERSALContraseña específica por entidad (opcional)
Todas las credenciales se registran como Secret Text en Jenkins. El pipeline las expone como variables de entorno con los mismos nombres que en el .env local para que Playwright no necesite saber si está corriendo en CI o en local.

Credenciales por entidad

En el Modo Despliegue, el pipeline puede utilizar credenciales diferentes para cada entidad mediante la función resolveCredentialIds(). El mecanismo funciona así:
  1. Toma el nombre de la entidad y lo convierte a mayúsculas (ej: pastoPASTO).
  2. Construye los IDs de credencial específicos: PASTO_USER y PASTO_PASS.
  3. Intenta resolver esas credenciales ejecutando un comando trivial (sh 'true') dentro de un bloque withCredentials. Si Jenkins puede inyectarlas sin error, existen.
  4. Si las credenciales específicas existen → las usa para esa entidad.
  5. Si no existen (lanza una excepción) → hace fallback a USER_GENERIC / PASSWORD_UNIVERSAL.
Este mecanismo de prueba está aislado de la ejecución real de tests, de modo que un fallo de prueba nunca se confunde con un error de resolución de credencial.
def resolveCredentialIds(String entidad) {
    def entidadUpper = entidad.toUpperCase()  // 'pasto' → 'PASTO'
    def specificUser = "${entidadUpper}_USER"  // 'PASTO_USER'
    def specificPass = "${entidadUpper}_PASS"  // 'PASTO_PASS'
    try {
        // Intenta usar credenciales específicas
        withCredentials([
            string(credentialsId: specificUser, variable: 'CHK_USER'),
            string(credentialsId: specificPass, variable: 'CHK_PASS')
        ]) {
            sh 'true'  // no-op, solo fuerza la resolución de la credencial
        }
        return [userCredId: specificUser, passCredId: specificPass, source: 'entidad']
    } catch (Exception e) {
        // Fallback a genéricas
        return [userCredId: 'USER_GENERIC', passCredId: 'PASSWORD_UNIVERSAL', source: 'generic']
    }
}
Ejemplo para la entidad pasto:
  • Busca PASTO_USER y PASTO_PASS en el almacén de Jenkins.
  • Si existen → el bloque withCredentials de ejecución los inyecta como USER_GENERIC y PASSWORD_UNIVERSAL.
  • Si no existen → usa las credenciales genéricas USER_GENERIC / PASSWORD_UNIVERSAL.
En modo all_entities_together, como hay múltiples entidades, el pipeline usa directamente las credenciales genéricas sin intentar resolución específica.

Configurar credenciales en Jenkins

1

Acceder al almacén de credenciales

En la pantalla principal de Jenkins, ve a Manage JenkinsManage Credentials. Selecciona el dominio donde quieres almacenar las credenciales (normalmente (global) bajo Jenkins).
2

Agregar nueva credencial

Haz clic en Add Credentials. En el campo Kind selecciona Secret text. Deja Scope en Global para que el pipeline del agente automatico_196 pueda accederla.
3

Establecer el ID y el valor

En el campo ID escribe exactamente el nombre esperado por el pipeline:
  • USER_GENERIC para el usuario genérico
  • PASSWORD_UNIVERSAL para la contraseña genérica
  • PASTO_USER / PASTO_PASS para credenciales específicas de la entidad pasto
  • CAJICA_USER / CAJICA_PASS para la entidad cajica, etc.
En el campo Secret escribe el valor real de la credencial. El campo Description es opcional pero recomendable para identificar el uso.
4

Guardar y verificar

Haz clic en Create (o OK). La credencial aparecerá en la lista del dominio. Para verificar que el pipeline puede accederla, puedes lanzar un build de prueba en integration con la entidad correspondiente y revisar en los logs el mensaje:
🔑 Usando credenciales específicas: PASTO_USER/PASTO_PASS
o si usa el fallback:
🔑 Sin credenciales específicas (PASTO_USER). Usando USER_GENERIC/PASSWORD_UNIVERSAL
En desarrollo local, las credenciales provienen del archivo .env en la raíz del proyecto. Copia .env.example a .env y rellena las variables USER_GENERIC y PASSWORD_UNIVERSAL con los valores reales de tu entorno de trabajo. El archivo .env está en .gitignore y nunca debe commitearse.
Nunca escribas credenciales reales en .env.example, en el Jenkinsfile, en archivos de fixtures, en specs, ni en ningún otro archivo versionado del repositorio. Si accidentalmente se exponen credenciales en un commit, cámbialas en el sistema inmediatamente y límpia el historial de git.

Build docs developers (and LLMs) love