गिटलैब में सीआई/सीडी के लिए एक गाइड (लगभग) निरपेक्ष शुरुआती के लिए

या आसान कोडिंग की एक शाम में अपने प्रोजेक्ट के लिए सुंदर बैज कैसे प्राप्त करें

शायद, प्रत्येक डेवलपर जिसके पास कम से कम एक पालतू परियोजना है, उसके पास स्थिति, कोड कवरेज, नगेट में पैकेज संस्करणों के साथ सुंदर बैज के बारे में एक खुजली है ... और इस खुजली ने मुझे यह लेख लिखने के लिए प्रेरित किया। इसे लिखने की तैयारी में, मुझे यह सुंदरता मेरी एक परियोजना में मिली:

यह लेख आपको GitLab में .Net Core क्लास लाइब्रेरी प्रोजेक्ट के लिए निरंतर एकीकरण और वितरण के बुनियादी सेटअप के बारे में बताएगा, GitLab पेजों के लिए दस्तावेज़ प्रकाशित करना, और Azure DevOps में निर्मित पैकेजों को एक निजी फ़ीड में धकेलना।

वीएस कोड का उपयोग विस्तार के साथ विकास के वातावरण के रूप में किया गया था गिटलैब वर्कफ़्लो (विकास वातावरण से सीधे सेटिंग फ़ाइल को मान्य करने के लिए)।

संक्षिप्त परिचय

सीडी - क्या यह तब है जब आपने सिर्फ धक्का दिया, और ग्राहक पर सब कुछ पहले ही गिर चुका है?

CI / CD क्या है और आपको इसकी आवश्यकता क्यों है - आप इसे आसानी से google कर सकते हैं। GitLab में पाइपलाइनों को कॉन्फ़िगर करने के लिए संपूर्ण दस्तावेज़ प्राप्त करें आसान भी. यहाँ मैं संक्षेप में और, यदि संभव हो तो, दोषों के बिना एक पक्षी की दृष्टि से प्रणाली की प्रक्रिया का वर्णन करूँगा:

• डेवलपर रिपॉजिटरी को एक कमिट भेजता है, साइट के माध्यम से एक मर्ज अनुरोध बनाता है, या किसी अन्य तरीके से, स्पष्ट रूप से या परोक्ष रूप से पाइपलाइन शुरू करता है,
• कॉन्फ़िगरेशन से सभी कार्यों का चयन किया जाता है, जिसकी शर्तें उन्हें दिए गए संदर्भ में लॉन्च करने की अनुमति देती हैं,
• कार्यों को उनके चरणों के अनुसार व्यवस्थित किया जाता है,
• चरणों को बारी-बारी से क्रियान्वित किया जाता है - अर्थात के समानांतर इस चरण के सभी कार्य पूरे हो चुके हैं,
• यदि चरण विफल हो जाता है (अर्थात, चरण का कम से कम एक कार्य विफल हो जाता है), तो पाइपलाइन बंद हो जाती है (ज्यादातर हमेशा),
• यदि सभी चरण सफलतापूर्वक पूरे हो जाते हैं, तो पाइपलाइन को सफल माना जाता है।

इस प्रकार, हमारे पास है:

• पाइपलाइन - चरणों में व्यवस्थित कार्यों का एक सेट जिसमें आप निर्माण कर सकते हैं, परीक्षण कर सकते हैं, पैकेज कोड कर सकते हैं, एक क्लाउड सेवा के लिए तैयार बिल्ड को तैनात कर सकते हैं, आदि।
• अवस्था (मंच) — पाइपलाइन संगठन इकाई, जिसमें 1+ कार्य शामिल है,
• काम (काम) पाइपलाइन में काम की एक इकाई है। इसमें एक स्क्रिप्ट (अनिवार्य), लॉन्च की शर्तें, प्रकाशन/कैशिंग कलाकृतियों के लिए सेटिंग्स, और बहुत कुछ शामिल हैं।

तदनुसार, सीआई / सीडी स्थापित करते समय कार्य कार्यों का एक सेट बनाने के लिए कम हो जाता है जो कोड और कलाकृतियों के निर्माण, परीक्षण और प्रकाशन के लिए सभी आवश्यक कार्यों को लागू करता है।

शुरू करने से पहले: क्यों?

• गिटलैब क्यों?

क्योंकि जब पालतू परियोजनाओं के लिए निजी रिपॉजिटरी बनाना आवश्यक हो गया, तो उन्हें गिटहब पर भुगतान किया गया, और मैं लालची था। रिपॉजिटरी मुक्त हो गई है, लेकिन अभी तक यह मेरे लिए गिटहब में जाने के लिए पर्याप्त कारण नहीं है।

• Azure DevOps पाइपलाइन क्यों नहीं?

क्योंकि वहां सेटिंग प्राथमिक है - कमांड लाइन के ज्ञान की भी आवश्यकता नहीं है। बाहरी गिट प्रदाताओं के साथ एकीकरण - कुछ क्लिकों में, रिपॉजिटरी को कमिट भेजने के लिए SSH कुंजियों का आयात - भी, पाइपलाइन आसानी से कॉन्फ़िगर की जाती है, यहां तक ​​​​कि एक टेम्पलेट से भी नहीं।

प्रारंभिक स्थिति: आपके पास क्या है और आप क्या चाहते हैं

हमारे पास:

• GitLab में रिपॉजिटरी।

हम चाहते हैं:

• प्रत्येक मर्ज अनुरोध के लिए स्वचालित असेंबली और परीक्षण,
• प्रत्येक मर्ज अनुरोध के लिए पैकेज बनाना और मास्टर को धक्का देना, बशर्ते प्रतिबद्ध संदेश में एक निश्चित रेखा हो,
• Azure DevOps में निजी फ़ीड में निर्मित पैकेज भेजना,
• GitLab पेजों में प्रलेखन और प्रकाशन की असेंबली,
• बैज!11

वर्णित आवश्यकताएं निम्नलिखित पाइपलाइन मॉडल पर व्यवस्थित रूप से आती हैं:

• स्टेज 1 - असेंबली
  • हम कोड एकत्र करते हैं, आउटपुट फाइलों को कलाकृतियों के रूप में प्रकाशित करते हैं
• स्टेज 2 - परीक्षण
  • हम बिल्ड स्टेज से कलाकृतियाँ प्राप्त करते हैं, परीक्षण चलाते हैं, कोड कवरेज डेटा एकत्र करते हैं
• स्टेज 3 - सबमिट करें
  • टास्क 1 - नगेट पैकेज बनाएं और इसे Azure DevOps को भेजें
  • टास्क 2 - हम स्रोत कोड में xmldoc से साइट एकत्र करते हैं और इसे GitLab पेजों में प्रकाशित करते हैं

आएँ शुरू करें!

विन्यास एकत्रित करना

खाते तैयार करना

1. में अकाउंट बनाएं माइक्रोसॉफ्ट नीला

2. के लिए जाओ Azure DevOps

3. हम एक नया प्रोजेक्ट बनाते हैं

   1. नाम - कोई भी
   2. दृश्यता - कोई भी
      

4. जब आप क्रिएट बटन पर क्लिक करते हैं, तो प्रोजेक्ट बन जाएगा और आप इसके पेज पर रीडायरेक्ट हो जाएंगे। इस पृष्ठ पर, आप प्रोजेक्ट सेटिंग्स (बाईं ओर सूची में निचला लिंक -> अवलोकन -> Azure DevOps Services ब्लॉक) पर जाकर अनावश्यक सुविधाओं को अक्षम कर सकते हैं।
   

5. Atrifacts पर जाएं, फ़ीड बनाएं पर क्लिक करें

   1. स्रोत का नाम दर्ज करें
   2. दृश्यता चुनें
   3. सही का निशान हटाएँ आम सार्वजनिक स्रोतों से पैकेज शामिल करें, ताकि स्रोत डंप नगेट क्लोन में न बदल जाए
      

6. कनेक्ट टू फीड पर क्लिक करें, विजुअल स्टूडियो का चयन करें, मशीन सेटअप ब्लॉक से स्रोत कॉपी करें
   

7. अकाउंट सेटिंग में जाएं, पर्सनल एक्सेस टोकन चुनें
   

8. एक नया एक्सेस टोकन बनाएं

   1. नाम - मनमाना
   2. संगठन - वर्तमान
   3. अधिकतम 1 वर्ष के लिए वैध
   4. कार्यक्षेत्र - पैकेजिंग/पढ़ें और लिखें
      

9. बनाए गए टोकन को कॉपी करें - मोडल विंडो बंद होने के बाद, मान अनुपलब्ध होगा

10. GitLab में रिपॉजिटरी सेटिंग्स पर जाएं, CI / CD सेटिंग्स चुनें
    

11. वेरिएबल्स ब्लॉक का विस्तार करें, एक नया जोड़ें

    1. नाम - रिक्त स्थान के बिना कोई भी (कमांड शेल में उपलब्ध होगा)
    2. मान - पैराग्राफ 9 से एक्सेस टोकन
    3. मास्क चर का चयन करें
       

यह पूर्व-कॉन्फ़िगरेशन को पूरा करता है।

कॉन्फ़िगरेशन फ्रेमवर्क तैयार करना

डिफ़ॉल्ट रूप से, GitLab में CI / CD कॉन्फ़िगरेशन फ़ाइल का उपयोग करता है .gitlab-ci.yml भंडार की जड़ से। आप रिपॉजिटरी सेटिंग्स में इस फ़ाइल के लिए एक मनमाना पथ सेट कर सकते हैं, लेकिन इस मामले में यह आवश्यक नहीं है।

जैसा कि आप एक्सटेंशन से देख सकते हैं, फ़ाइल में प्रारूप में एक कॉन्फ़िगरेशन है YAML. दस्तावेज़ीकरण विवरण कॉन्फ़िगरेशन के शीर्ष स्तर पर और प्रत्येक नेस्टेड स्तर पर कौन सी कुंजियाँ समाहित की जा सकती हैं।

सबसे पहले, कॉन्फ़िगरेशन फ़ाइल में डॉकर छवि के लिए एक लिंक जोड़ें, जिसमें कार्य किए जाएंगे। इसके लिए हम पाते हैं डॉकर हब पर नेट कोर इमेज पेज. में GitHub विभिन्न कार्यों के लिए किस छवि को चुनना है, इस पर एक विस्तृत मार्गदर्शिका है। .Net Core 3.1 वाली एक छवि हमारे निर्माण के लिए उपयुक्त है, इसलिए कॉन्फ़िगरेशन में पहली पंक्ति जोड़ने के लिए स्वतंत्र महसूस करें

image: mcr.microsoft.com/dotnet/core/sdk:3.1

अब, जब Microsoft छवि रिपॉजिटरी से पाइपलाइन लॉन्च की जाती है, तो निर्दिष्ट छवि डाउनलोड की जाएगी, जिसमें कॉन्फ़िगरेशन से सभी कार्य निष्पादित किए जाएंगे।

अगला कदम जोड़ना है मंच'एस। डिफ़ॉल्ट रूप से, GitLab 5 चरणों को परिभाषित करता है:

• .pre - सभी चरणों तक प्रदर्शन किया,
• .post - सभी चरणों के बाद प्रदर्शन किया,
• build - पहले के बाद .pre अवस्था,
• test - दूसरा चरण,
• deploy - तीसरा चरण।

हालाँकि, आपको उन्हें स्पष्ट रूप से घोषित करने से कोई नहीं रोकता है। जिस क्रम में चरणों को सूचीबद्ध किया गया है वह उस क्रम को प्रभावित करता है जिसमें वे किए जाते हैं। पूर्णता के लिए, आइए कॉन्फ़िगरेशन में जोड़ें:

stages:
  - build
  - test
  - deploy

डिबगिंग के लिए, उस वातावरण के बारे में जानकारी प्राप्त करना समझ में आता है जिसमें कार्य निष्पादित किए जाते हैं। आइए कमांड का एक वैश्विक सेट जोड़ते हैं जिसे प्रत्येक कार्य से पहले निष्पादित किया जाएगा before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

यह कम से कम एक कार्य जोड़ना बाकी है ताकि जब कमिट भेजा जाए तो पाइपलाइन शुरू हो जाए। अभी के लिए, प्रदर्शित करने के लिए एक खाली कार्य जोड़ें:

dummy job:
  script:
    - echo ok

हम सत्यापन शुरू करते हैं, हमें एक संदेश मिलता है कि सब कुछ ठीक है, हम प्रतिबद्ध हैं, हम धक्का देते हैं, हम साइट पर परिणाम देखते हैं ... और हमें एक स्क्रिप्ट त्रुटि मिलती है - bash: .PSVersion: command not found. डब्ल्यूटीएफ?

सब कुछ तार्किक है - डिफ़ॉल्ट रूप से, धावक (कार्य स्क्रिप्ट को निष्पादित करने के लिए जिम्मेदार और GitLab द्वारा प्रदान किया गया) उपयोग करते हैं bash आदेशों को क्रियान्वित करने के लिए। आप कार्य विवरण में स्पष्ट रूप से निर्दिष्ट करके इसे ठीक कर सकते हैं कि निष्पादन पाइपलाइन रनर में कौन से टैग होने चाहिए:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

महान! अभी पाइपलाइन चल रही है।

एक चौकस पाठक, संकेतित चरणों को दोहराते हुए, ध्यान देगा कि कार्य चरण में पूरा हो गया था test, हालांकि हमने चरण निर्दिष्ट नहीं किया। जैसा आप अनुमान लगा सकते हैं test डिफ़ॉल्ट कदम है।

आइए ऊपर वर्णित सभी कार्यों को जोड़कर कॉन्फ़िगरेशन कंकाल बनाना जारी रखें:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

हमें विशेष रूप से कार्यात्मक नहीं मिला, लेकिन फिर भी सही पाइपलाइन।

ट्रिगर्स की स्थापना

इस तथ्य के कारण कि किसी भी कार्य के लिए कोई ट्रिगर फ़िल्टर निर्दिष्ट नहीं है, पाइपलाइन होगा पूरी तरह से हर बार एक कमिट को रिपॉजिटरी में धकेलने पर निष्पादित किया जाएगा। चूंकि यह सामान्य रूप से वांछित व्यवहार नहीं है, इसलिए हम कार्यों के लिए ट्रिगर फ़िल्टर सेट अप करेंगे।

फ़िल्टर को दो स्वरूपों में कॉन्फ़िगर किया जा सकता है: केवल/छोड़कर и नियम. संक्षेप में, only/except आपको ट्रिगर द्वारा फ़िल्टर कॉन्फ़िगर करने की अनुमति देता है (merge_request, उदाहरण के लिए - हर बार एक पुल अनुरोध बनाए जाने पर कार्य को निष्पादित करने के लिए सेट करता है और हर बार कमिट उस शाखा को भेजा जाता है जो मर्ज अनुरोध में स्रोत है) और शाखा के नाम (नियमित अभिव्यक्ति का उपयोग करने सहित); rules आपको शर्तों के एक सेट को अनुकूलित करने की अनुमति देता है और, वैकल्पिक रूप से, पिछले कार्यों की सफलता के आधार पर कार्य निष्पादन की स्थिति को बदल देता है (when गिटलैब सीआई/सीडी में).

आइए आवश्यकताओं के एक सेट को याद करें - केवल मर्ज अनुरोध के लिए असेंबली और परीक्षण, Azure DevOps को पैकेजिंग और भेजना - मर्ज अनुरोध के लिए और मास्टर को पुश करना, प्रलेखन बनाना - मास्टर को पुश करने के लिए।

सबसे पहले, एक नियम जोड़कर कोड बिल्ड टास्क सेट करते हैं जो केवल मर्ज अनुरोध पर सक्रिय होता है:

build job:
  # snip
  only:
    - merge_request

अब पैकेजिंग कार्य को मर्ज अनुरोध पर आग लगाने के लिए सेट करें और मास्टर को कमिट जोड़ें:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

जैसा कि आप देख सकते हैं, सब कुछ सरल और सीधा है।

आप कार्य को सक्रिय करने के लिए भी सेट कर सकते हैं यदि किसी विशिष्ट लक्ष्य या स्रोत शाखा के साथ मर्ज अनुरोध बनाया गया हो:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

शर्तों के तहत, आप उपयोग कर सकते हैं यहाँ सूचीबद्ध चर; नियम rules नियमों के साथ असंगत only/except.

आर्टिफैक्ट सेविंग को कॉन्फ़िगर करना

एक टास्क के दौरान build job हमारे पास ऐसी कलाकृतियाँ होंगी जिनका बाद के कार्यों में पुन: उपयोग किया जा सकता है। ऐसा करने के लिए, आपको कार्य कॉन्फ़िगरेशन में पथ जोड़ने की आवश्यकता है, वे फ़ाइलें जिनके साथ आपको निम्नलिखित कार्यों में सहेजने और पुन: उपयोग करने की आवश्यकता होगी, कुंजी में artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

पथ वाइल्डकार्ड का समर्थन करते हैं, जो निश्चित रूप से उन्हें सेट करना आसान बनाता है।

यदि कोई कार्य कलाकृतियों का निर्माण करता है, तो प्रत्येक बाद का कार्य उन्हें एक्सेस करने में सक्षम होगा - वे रिपॉजिटरी रूट के सापेक्ष उन्हीं रास्तों पर स्थित होंगे जो मूल कार्य से एकत्र किए गए थे। साइट पर डाउनलोड करने के लिए कलाकृतियाँ भी उपलब्ध हैं।

अब जबकि हमारे पास एक कॉन्फ़िगरेशन फ्रेमवर्क तैयार है (और परीक्षण किया गया है), हम वास्तव में कार्यों के लिए स्क्रिप्ट लिखने के लिए आगे बढ़ सकते हैं।

हम स्क्रिप्ट लिखते हैं

शायद, एक बार एक आकाशगंगा में, बहुत दूर, कमांड लाइन से परियोजनाओं (नेट पर उन सहित) का निर्माण एक दर्द था। अब आप 3 टीमों में प्रोजेक्ट बना सकते हैं, परीक्षण कर सकते हैं और प्रकाशित कर सकते हैं:

dotnet build
dotnet test
dotnet pack

स्वाभाविक रूप से, कुछ बारीकियाँ हैं जिसके कारण हम कुछ हद तक आज्ञाओं को जटिल बना देंगे।

1. हम रिलीज बिल्ड चाहते हैं, डिबग बिल्ड नहीं, इसलिए हम प्रत्येक कमांड में जोड़ते हैं -c Release
2. परीक्षण करते समय, हम कोड कवरेज डेटा एकत्र करना चाहते हैं, इसलिए हमें परीक्षण पुस्तकालयों में एक कवरेज विश्लेषक शामिल करने की आवश्यकता है:
   1. पैकेज को सभी परीक्षण पुस्तकालयों में जोड़ें coverlet.msbuild: dotnet add package coverlet.msbuild प्रोजेक्ट फ़ोल्डर से
   2. टेस्ट रन कमांड में जोड़ें /p:CollectCoverage=true
   3. कवरेज परिणाम प्राप्त करने के लिए परीक्षण कार्य कॉन्फ़िगरेशन में कुंजी जोड़ें (नीचे देखें)
3. कोड को नगेट पैकेज में पैक करते समय, पैकेज के लिए आउटपुट डायरेक्टरी सेट करें: -o .

कोड कवरेज डेटा एकत्रित करना

परीक्षण चलाने के बाद, कवरलेट प्रिंट कंसोल पर आंकड़े चलाते हैं:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab आपको आँकड़े प्राप्त करने के लिए एक नियमित अभिव्यक्ति निर्दिष्ट करने की अनुमति देता है, जिसे तब बैज के रूप में प्राप्त किया जा सकता है। कुंजी के साथ कार्य सेटिंग्स में नियमित अभिव्यक्ति निर्दिष्ट है coverage; अभिव्यक्ति में एक कैप्चर समूह होना चाहिए, जिसका मान बैज को दिया जाएगा:

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

यहां हम कुल लाइन कवरेज वाली एक लाइन से आंकड़े प्राप्त करते हैं।

पैकेज और दस्तावेज प्रकाशित करें

दोनों क्रियाएं पाइपलाइन के अंतिम चरण के लिए निर्धारित हैं - चूंकि असेंबली और परीक्षण पास हो चुके हैं, हम अपने विकास को दुनिया के साथ साझा कर सकते हैं।

पहले, पैकेज स्रोत पर प्रकाशन पर विचार करें:

1. यदि प्रोजेक्ट में नगेट कॉन्फ़िगरेशन फ़ाइल नहीं है (nuget.config), एक नया बनाएँ: dotnet new nugetconfig

   किसलिए: छवि में वैश्विक (उपयोगकर्ता और मशीन) कॉन्फ़िगरेशन तक लिखने की पहुंच नहीं हो सकती है। त्रुटियों को न पकड़ने के लिए, हम केवल एक नया स्थानीय कॉन्फ़िगरेशन बनाते हैं और इसके साथ काम करते हैं।

2. आइए स्थानीय कॉन्फ़िगरेशन में एक नया पैकेज स्रोत जोड़ें: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. name - स्थानीय स्रोत का नाम, महत्वपूर्ण नहीं
   2. url - "खाता तैयार करना" चरण से स्रोत का URL, पृष्ठ 6
   3. organization - Azure DevOps में संगठन का नाम
   4. gitlab variable - एक्सेस टोकन के साथ वेरिएबल का नाम GitLab ("खाता तैयार करना", पृष्ठ 11) में जोड़ा गया। स्वाभाविक रूप से, प्रारूप में $variableName
   5. -StorePasswordInClearText - पहुँच अस्वीकृत त्रुटि को बायपास करने के लिए एक हैक (मैं इस रेक पर कदम रखने वाला पहला व्यक्ति नहीं हूं)
   6. त्रुटियों के मामले में, जोड़ना उपयोगी हो सकता है -verbosity detailed
3. पैकेज को स्रोत पर भेजना: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. हम वर्तमान निर्देशिका से सभी पैकेज भेजते हैं, इसलिए *.nupkg.
   2. name - ऊपर के चरण से।
   3. key - कोई रेखा। Azure DevOps में, फ़ीड से कनेक्ट करें विंडो में, उदाहरण हमेशा रेखा होता है az.
   4. -skipduplicate - इस कुंजी के बिना पहले से मौजूद पैकेज भेजने का प्रयास करते समय, स्रोत एक त्रुटि लौटाएगा 409 Conflict; कुंजी के साथ, भेजना छोड़ दिया जाएगा।

अब चलिए प्रलेखन के निर्माण की स्थापना करते हैं:

1. सबसे पहले, रिपॉजिटरी में, मास्टर ब्रांच में, हम docfx प्रोजेक्ट को इनिशियलाइज़ करते हैं। ऐसा करने के लिए, रूट से कमांड चलाएँ docfx init और प्रलेखन के निर्माण के लिए प्रमुख मापदंडों को अंतःक्रियात्मक रूप से सेट करें। न्यूनतम परियोजना सेटअप का विस्तृत विवरण यहां.
   1. कॉन्फ़िगर करते समय, आउटपुट निर्देशिका को निर्दिष्ट करना महत्वपूर्ण है ..public - GitLab डिफ़ॉल्ट रूप से सार्वजनिक फ़ोल्डर की सामग्री को रिपॉजिटरी के रूट में पेज के स्रोत के रूप में लेता है। क्योंकि प्रोजेक्ट रिपॉजिटरी में नेस्टेड फ़ोल्डर में स्थित होगा - पथ में ऊपर के स्तर पर एक आउटपुट जोड़ें।
2. आइए परिवर्तनों को GitLab में आगे बढ़ाते हैं।
3. पाइपलाइन कॉन्फ़िगरेशन में कोई कार्य जोड़ें pages (GitLab पेजों में साइट प्रकाशन कार्यों के लिए आरक्षित शब्द):
   1. लिखी हुई कहानी:
      1. nuget install docfx.console -version 2.51.0 - डॉकएफएक्स स्थापित करें; संस्करण यह सुनिश्चित करने के लिए निर्दिष्ट किया गया है कि पैकेज स्थापना पथ सही हैं।
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - दस्तावेज एकत्रित करना
   2. नोड कलाकृतियाँ:

pages:
  # snip
  artifacts:
    paths:
      - public

Docfx के बारे में गीतात्मक विषयांतर

पहले, एक परियोजना की स्थापना करते समय, मैंने समाधान फ़ाइल के रूप में प्रलेखन के लिए कोड स्रोत निर्दिष्ट किया था। मुख्य नुकसान यह है कि परीक्षण परियोजनाओं के लिए प्रलेखन भी बनाया जाता है। यदि यह आवश्यक नहीं है, तो आप इस मान को नोड पर सेट कर सकते हैं metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

1. metadata.src.src: "../" - हम स्थान के सापेक्ष एक स्तर ऊपर जाते हैं docfx.json, क्योंकि पैटर्न में, डायरेक्टरी ट्री को खोजना काम नहीं करता है।
2. metadata.src.files: ["**/*.csproj"] - एक वैश्विक पैटर्न, हम सभी निर्देशिकाओं से सभी C # प्रोजेक्ट एकत्र करते हैं।
3. metadata.src.exclude: ["*.tests*/**"] - वैश्विक पैटर्न, फ़ोल्डर से सब कुछ बाहर करें .tests नाम में

उप-योग

इस तरह के एक सरल कॉन्फ़िगरेशन को केवल आधे घंटे और कुछ कप कॉफी में बनाया जा सकता है, जो आपको यह जांचने की अनुमति देगा कि कोड बनाया गया है और परीक्षण पास हो गए हैं, एक नया पैकेज बनाएं, दस्तावेज़ीकरण अपडेट करें और आंखों को सुंदर बनाएं प्रत्येक विलय अनुरोध और मास्टर को भेजने के साथ परियोजना के रीडमे में बैज।

अंतिम .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

बैज की बात हो रही है

उन्हीं की वजह से आखिर सब कुछ शुरू हुआ!

Gtntral पाइपलाइन ब्लॉक में CI/CD सेटिंग में GitLab में पाइपलाइन स्थिति और कोड कवरेज वाले बैज उपलब्ध हैं:

मैंने प्लेटफ़ॉर्म पर दस्तावेज़ों के लिंक के साथ एक बैज बनाया है शील्ड्स.आईओ - वहां सब कुछ काफी सीधा है, आप अपना खुद का बैज बना सकते हैं और एक अनुरोध का उपयोग करके इसे प्राप्त कर सकते हैं।

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps कलाकृतियाँ आपको नवीनतम संस्करण वाले पैकेजों के लिए बैज बनाने की अनुमति भी देती हैं। ऐसा करने के लिए, Azure DevOps साइट पर स्रोत में, आपको चयनित पैकेज के लिए क्रिएट बैज पर क्लिक करना होगा और मार्कडाउन मार्कअप को कॉपी करना होगा:

सुंदरता जोड़ना

सामान्य कॉन्फ़िगरेशन फ़्रैगमेंट हाइलाइट करना

कॉन्फ़िगरेशन लिखते समय और प्रलेखन के माध्यम से खोज करते समय, मुझे YAML की एक दिलचस्प विशेषता मिली - टुकड़ों का पुन: उपयोग करना।

जैसा कि आप कार्य सेटिंग्स से देख सकते हैं, उन सभी को टैग की आवश्यकता होती है windows धावक पर, और ट्रिगर किया जाता है जब मर्ज अनुरोध मास्टर/निर्मित (दस्तावेज़ को छोड़कर) भेजा जाता है। आइए इसे उस टुकड़े में जोड़ें जिसका हम पुन: उपयोग करेंगे:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

और अब हम कार्य विवरण में पहले घोषित किए गए टुकड़े को सम्मिलित कर सकते हैं:

build job:
  <<: *common_tags
  <<: *common_only

फ़्रैगमेंट के नाम डॉट से शुरू होने चाहिए, ताकि इसे किसी कार्य के रूप में न समझा जाए।

पैकेज वर्जनिंग

पैकेज बनाते समय, कंपाइलर कमांड लाइन स्विच की जाँच करता है, और उनकी अनुपस्थिति में, प्रोजेक्ट फ़ाइलें; जब इसे एक संस्करण नोड मिलता है, तो यह इसके मूल्य को बनाए जा रहे पैकेज के संस्करण के रूप में लेता है। यह पता चला है कि एक नए संस्करण के साथ एक पैकेज बनाने के लिए, आपको या तो इसे प्रोजेक्ट फ़ाइल में अपडेट करना होगा या इसे कमांड लाइन तर्क के रूप में पास करना होगा।

आइए एक और विशलिस्ट जोड़ें - संस्करण में माइनर दो नंबरों को वर्ष और पैकेज की निर्माण तिथि होने दें, और पूर्व-रिलीज़ संस्करण जोड़ें। बेशक, आप इस डेटा को प्रोजेक्ट फ़ाइल में जोड़ सकते हैं और प्रत्येक सबमिशन से पहले जांच कर सकते हैं - लेकिन आप इसे पाइपलाइन में भी कर सकते हैं, संदर्भ से पैकेज संस्करण एकत्र कर सकते हैं और इसे कमांड लाइन तर्क के माध्यम से पास कर सकते हैं।

आइए सहमत हैं कि अगर प्रतिबद्ध संदेश में एक पंक्ति है release (v./ver./version) <version number> (rev./revision <revision>)?, फिर हम इस लाइन से पैकेज का संस्करण लेंगे, इसे वर्तमान तिथि के साथ पूरक करेंगे और इसे कमांड के तर्क के रूप में पास करेंगे dotnet pack. लाइन के अभाव में, हम बस पैकेज एकत्र नहीं करेंगे।

निम्न स्क्रिप्ट इस समस्या को हल करती है:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

किसी कार्य में स्क्रिप्ट जोड़ना pack and deploy job और प्रतिबद्ध संदेश में दिए गए स्ट्रिंग की उपस्थिति में पैकेजों की असेंबली का सख्ती से निरीक्षण करें।

कुल मिलाकर

कॉन्फ़िगरेशन लिखने में लगभग आधा घंटा या एक घंटा बिताने के बाद, स्थानीय पॉवरशेल में डिबगिंग और, संभवतः, कुछ असफल लॉन्च, हमें नियमित कार्यों को स्वचालित करने के लिए एक सरल कॉन्फ़िगरेशन मिला।

बेशक, GitLab CI / CD इस गाइड को पढ़ने के बाद जितना लगता है उससे कहीं अधिक व्यापक और बहुमुखी है - यह पूरी तरह से गलत है. वहाँ भी ऑटो DevOps हैकी इजाजत दी

स्वचालित रूप से आपके एप्लिकेशन का पता लगाता है, बनाता है, परीक्षण करता है, तैनात करता है और निगरानी करता है

अब योजना एज़्योर में अनुप्रयोगों को तैनात करने के लिए, पुलुमी का उपयोग करने और स्वचालित रूप से लक्ष्य वातावरण का निर्धारण करने के लिए एक पाइपलाइन को कॉन्फ़िगर करने की है, जिसे अगले लेख में शामिल किया जाएगा।

स्रोत: www.habr.com