GitLab चरणले जागिरहरूलाई समूहबद्ध गर्छ; योसँग छुट्टै प्रक्रिया वातावरण हुँदैन। प्रोक्सी भेरिएबलहरू तिनीहरू चाहिने जागिरहरूमा राख्नुहोस्, चाहे त पुन: प्रयोग गर्न मिल्ने लुकेको टेम्प्लेटमार्फत:

.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 परियोजनाको विद्यमान भेरिएबल व्यवस्थापनमार्फत उपलब्ध गराइन्छ। सार्वजनिक प्रोक्सीमार्फत सार्वजनिक सेवाहरूमा पहुँच गर्न अनुमति दिइएका जागिरहरूका लागि, यसको मानले HTTP प्रोक्सी सूचीबाट HTTP अन्त्यबिन्दु प्रयोग गर्न सक्छ। Python आदेश एउटा उदाहरण परियोजना कार्य हो। अन्य जागिरहरूले यो टेम्प्लेट छोड्न सक्छन्, र एउटै चरणका धेरै जागिरहरूले फरक वातावरण छान्न सक्छन्।

यी प्रोक्सी नामहरू व्यापक रूपमा वंशानुगत हुनु नपर्ने भए माथिल्लो तहको YAML पूर्वनिर्धारितबाट बाहिर राख्नुहोस्। परियोजना, समूह र पाइपलाइन भेरिएबलहरू पनि जाँच्नुहोस्: तिनको प्राथमिकताले जागिरको YAML मानलाई अधिलेखन गर्न सक्छ।

inherit:variables ले YAML पूर्वनिर्धारित भेरिएबलहरूको वंशानुगत नियन्त्रण गर्छ। यसले परियोजना वा समूह CI/CD भेरिएबलहरू मेटाउँदैन, त्यसैले हरेक प्रोक्सी स्रोत हटाउन यो सामान्य स्विच होइन।

यसले जागिर प्रक्रिया कन्फिगर गर्छ। यसभित्र सुरु गरिएको HTTP क्लाइन्टले ती भेरिएबलहरू समर्थन गर्नुपर्छ, र रनरको पहिलेको इमेज-पुल जडानको आफ्नै कन्फिगरेसन छ।

सम्बन्धित लेखहरू