Les variables de proxy appartiennent aux tâches GitLab qui en ont besoin

Réutilisez un modèle de tâche masqué pour limiter l'environnement de proxy sans en faire une valeur par défaut pour tout le pipeline.

Une étape GitLab regroupe des tâches ; elle ne possède pas d'environnement de processus distinct. Placez les variables de proxy sur les tâches qui en ont besoin, éventuellement via un modèle masqué réutilisable :

.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 est fourni par la gestion des variables existante du projet. Pour les tâches autorisées à accéder aux services publics via des proxys publics, sa valeur peut utiliser un point de terminaison HTTP de la liste de proxys HTTP. La commande Python est une tâche de projet illustrative. Les autres tâches peuvent omettre ce modèle, et plusieurs tâches d'une même étape peuvent choisir des environnements différents.

Laissez ces noms de proxy hors des valeurs YAML par défaut de premier niveau s'ils ne doivent pas être hérités largement. Inspectez aussi les variables de projet, de groupe et de pipeline : leur priorité peut remplacer la valeur YAML d'une tâche.

inherit:variables contrôle l'héritage des variables YAML par défaut. Il n'efface pas les variables CI/CD de projet ou de groupe ; ce n'est donc pas un interrupteur général pour supprimer toutes les sources de proxy.

Ceci configure le processus de la tâche. Le client HTTP lancé à l'intérieur doit prendre en charge ces variables, et la connexion antérieure du runner pour tirer l'image a sa propre configuration.

Articles similaires