Las variables de proxy pertenecen a los trabajos de GitLab que las necesitan

Reutilice una plantilla de trabajo oculta para limitar el entorno de proxy sin convertirlo en un valor predeterminado de todo el pipeline.

Una etapa de GitLab agrupa trabajos; no posee un entorno de proceso separado. Coloque las variables de proxy en los trabajos que las necesitan, opcionalmente mediante una plantilla oculta reutilizable:

.proxy-environment:
  variables:
    HTTP_PROXY: "$CODE_PROXY"
    HTTPS_PROXY: "$CODE_PROXY"
    NO_PROXY: "localhost,127.0.0.1"

external_check:
  extends: .proxy-environment
  stage: test
  script:
    - python ci/check_external_service.py

CODE_PROXY se suministra a través de la gestión de variables existente del proyecto. Para los trabajos autorizados a acceder a servicios públicos mediante proxies públicos, su valor puede usar un punto de conexión HTTP de la lista de proxies HTTP. El comando de Python es una tarea de proyecto ilustrativa. Otros trabajos pueden omitir esta plantilla, y varios trabajos de la misma etapa pueden elegir entornos distintos.

Deje estos nombres de proxy fuera de los valores YAML predeterminados de nivel superior si no deben heredarse de forma amplia. Revise también las variables de proyecto, grupo y pipeline: su precedencia puede anular el valor YAML de un trabajo.

inherit:variables controla la herencia de las variables YAML predeterminadas. No borra las variables CI/CD de proyecto o grupo, así que no es un interruptor general para eliminar todas las fuentes de proxy.

Esto configura el proceso del trabajo. El cliente HTTP iniciado dentro debe admitir esas variables, y la conexión anterior del runner para descargar la imagen tiene su propia configuración.

Artículos relacionados