Variabilele proxy aparțin joburilor GitLab care au nevoie de ele

Reutilizați un șablon de job ascuns pentru a limita mediul proxy fără a-l face o valoare implicită pentru tot pipeline-ul.

O etapă GitLab grupează joburi; nu deține un mediu de proces separat. Puneți variabilele proxy pe joburile care au nevoie de ele, opțional printr-un șablon ascuns reutilizabil:

.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 este furnizat prin gestionarea existentă a variabilelor proiectului. Pentru joburile permise să acceseze servicii publice prin proxy-uri publice, valoarea sa poate folosi un endpoint HTTP din lista de proxy-uri HTTP. Comanda Python este o sarcină de proiect ilustrativă. Alte joburi pot omite acest șablon, iar mai multe joburi din aceeași etapă pot alege medii diferite.

Lăsați aceste nume de proxy în afara valorilor implicite YAML de nivel superior dacă nu trebuie moștenite pe scară largă. Inspectați și variabilele de proiect, grup și pipeline: precedența lor poate suprascrie valoarea YAML a unui job.

inherit:variables controlează moștenirea variabilelor implicite YAML. Nu șterge variabilele CI/CD de proiect sau grup, deci nu este un comutator general pentru eliminarea fiecărei surse de proxy.

Aceasta configurează procesul jobului. Clientul HTTP lansat în interior trebuie să accepte acele variabile, iar conexiunea anterioară a runner-ului pentru descărcarea imaginii are propria configurație.

Articole similare