Proxy-Variablen gehören zu den GitLab-Jobs, die sie brauchen

Verwenden Sie eine versteckte Job-Vorlage wieder, um die Proxy-Umgebung einzugrenzen, ohne sie zum pipelineweiten Standard zu machen.

Eine GitLab-Stage gruppiert Jobs; sie besitzt keine eigene Prozessumgebung. Legen Sie Proxy-Variablen bei den Jobs ab, die sie brauchen, optional über eine wiederverwendbare versteckte Vorlage:

.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 wird über die vorhandene Variablenverwaltung des Projekts bereitgestellt. Für Jobs, die über öffentliche Proxys auf öffentliche Dienste zugreifen dürfen, kann der Wert einen HTTP-Endpunkt aus der HTTP-Proxy-Liste verwenden. Der Python-Befehl ist eine beispielhafte Projektaufgabe. Andere Jobs können diese Vorlage weglassen, und mehrere Jobs derselben Stage können unterschiedliche Umgebungen wählen.

Lassen Sie diese Proxy-Namen aus den YAML-Standardwerten der obersten Ebene heraus, wenn sie nicht breit vererbt werden sollen. Prüfen Sie außerdem Projekt-, Gruppen- und Pipeline-Variablen: Ihre Priorität kann den YAML-Wert eines Jobs überschreiben.

inherit:variables steuert die Vererbung von YAML-Standardvariablen. Es löscht keine Projekt- oder Gruppen-CI/CD-Variablen und ist daher kein allgemeiner Schalter zum Entfernen jeder Proxy-Quelle.

Dies konfiguriert den Job-Prozess. Der darin gestartete HTTP-Client muss diese Variablen unterstützen, und die frühere Image-Pull-Verbindung des Runners hat ihre eigene Konfiguration.

Ähnliche Artikel