คำแนะนำเกี่ยวกับ CI/CD ใน GitLab สำหรับผู้เริ่มต้นที่ (เกือบ) สมบูรณ์

หรือวิธีรับป้ายที่สวยงามสำหรับโครงการของคุณในเย็นวันหนึ่งด้วยการเขียนโค้ดง่ายๆ

อาจเป็นไปได้ว่านักพัฒนาทุกคนที่มีโปรเจ็กต์สัตว์เลี้ยงอย่างน้อยหนึ่งโปรเจกต์อาจมีอาการคันเกี่ยวกับตราที่สวยงามพร้อมสถานะ ความครอบคลุมของโค้ด เวอร์ชันแพ็คเกจใน nuget ... และอาการคันนี้ทำให้ฉันเขียนบทความนี้ ในการเตรียมการเขียน ฉันได้ความงามนี้ในโครงการหนึ่งของฉัน:

บทความนี้จะแนะนำคุณเกี่ยวกับการตั้งค่าพื้นฐานของการผสานรวมอย่างต่อเนื่องและการส่งมอบสำหรับโครงการไลบรารีคลาส .Net Core ใน GitLab การเผยแพร่เอกสารไปยัง GitLab Pages และการพุชแพ็คเกจที่สร้างขึ้นไปยังฟีดส่วนตัวใน Azure DevOps

รหัส VS ถูกใช้เป็นสภาพแวดล้อมการพัฒนาพร้อมส่วนขยาย ขั้นตอนการทำงานของ GitLab (สำหรับตรวจสอบไฟล์การตั้งค่าโดยตรงจากสภาพแวดล้อมการพัฒนา)

แนะนำสั้น ๆ

ซีดี - เมื่อคุณเพิ่งกดและทุกอย่างตกลงบนไคลเอนต์แล้วหรือยัง

CI / CD คืออะไรและทำไมคุณถึงต้องการ - คุณสามารถ google ได้อย่างง่ายดาย ค้นหาเอกสารฉบับสมบูรณ์เกี่ยวกับการกำหนดค่าไปป์ไลน์ใน GitLab ยังง่าย. ฉันจะอธิบายกระบวนการของระบบโดยสังเขปและถ้าเป็นไปได้โดยไม่มีข้อบกพร่อง:

• นักพัฒนาส่งข้อตกลงไปยังพื้นที่เก็บข้อมูล สร้างคำขอผสานผ่านไซต์ หรือด้วยวิธีอื่น เริ่มต้นไปป์ไลน์โดยชัดแจ้งหรือโดยปริยาย,
• งานทั้งหมดถูกเลือกจากการกำหนดค่า เงื่อนไขที่อนุญาตให้เปิดใช้งานในบริบทที่กำหนด
• งานถูกจัดระเบียบตามขั้นตอน
• ขั้นตอนจะดำเนินการตามลำดับ - เช่น ขนาน งานทั้งหมดของขั้นตอนนี้เสร็จสมบูรณ์
• หากสเตจล้มเหลว (เช่น งานอย่างน้อยหนึ่งอย่างของสเตจล้มเหลว) ไปป์ไลน์จะหยุด (เกือบตลอดเวลา),
• หากเสร็จสิ้นทุกขั้นตอนถือว่าไปป์ไลน์สำเร็จ

ดังนั้นเรามี:

• ไปป์ไลน์ - ชุดของงานที่จัดระเบียบเป็นระยะซึ่งคุณสามารถสร้าง ทดสอบ โค้ดแพ็คเกจ ปรับใช้บิลด์ที่เสร็จแล้วกับบริการคลาวด์ ฯลฯ
• เวที (เวที) — หน่วยองค์กรไปป์ไลน์ มี 1+ งาน
• งาน (งาน) เป็นหน่วยงานหนึ่งในท่อส่ง ประกอบด้วยสคริปต์ (จำเป็น) เงื่อนไขการเปิดใช้งาน การตั้งค่าสำหรับการเผยแพร่/การแคชอาร์ติแฟกต์ และอื่นๆ อีกมากมาย

ดังนั้น งานเมื่อตั้งค่า CI / CD จึงลงมาที่การสร้างชุดงานที่ดำเนินการที่จำเป็นทั้งหมดสำหรับการสร้าง การทดสอบ และการเผยแพร่รหัสและสิ่งประดิษฐ์

ก่อนเริ่ม: ทำไม?

• ทำไมต้อง Gitlab?

เพราะเมื่อจำเป็นต้องสร้างพื้นที่เก็บข้อมูลส่วนตัวสำหรับโครงการสัตว์เลี้ยง พวกเขาได้รับเงินบน GitHub และฉันก็โลภมาก ที่เก็บกลายเป็นฟรี แต่จนถึงตอนนี้นี่ยังไม่เพียงพอสำหรับฉันที่จะย้ายไปที่ GitHub

• ทำไมไม่ Azure DevOps ไปป์ไลน์

เนื่องจากมีการตั้งค่าเป็นพื้นฐาน - ไม่จำเป็นต้องมีความรู้เกี่ยวกับบรรทัดคำสั่งด้วยซ้ำ การผสานรวมกับผู้ให้บริการคอมไพล์ภายนอก - ในไม่กี่คลิก นำเข้าคีย์ SSH เพื่อส่งคอมมิตไปยังที่เก็บ - เช่นกัน ไปป์ไลน์สามารถกำหนดค่าได้ง่ายแม้ไม่ได้มาจากเทมเพลต

ตำแหน่งเริ่มต้น: สิ่งที่คุณมีและสิ่งที่คุณต้องการ

เรามี:

• พื้นที่เก็บข้อมูลใน GitLab

พวกเราต้องการ:

• การประกอบและการทดสอบอัตโนมัติสำหรับคำขอผสานแต่ละรายการ
• สร้างแพ็คเกจสำหรับแต่ละคำขอผสานและพุชไปยังมาสเตอร์ โดยมีเงื่อนไขว่าจะมีบางบรรทัดในข้อความคอมมิต
• ส่งแพ็คเกจที่สร้างขึ้นไปยังฟีดส่วนตัวใน Azure DevOps
• การประกอบเอกสารและการเผยแพร่ใน GitLab Pages
• ป้าย!11

ข้อกำหนดที่อธิบายไว้นั้นเป็นไปตามรูปแบบไปป์ไลน์ต่อไปนี้:

• ขั้นตอนที่ 1 - การประกอบ
  • เรารวบรวมรหัส เผยแพร่ไฟล์เอาต์พุตเป็นสิ่งประดิษฐ์
• ขั้นตอนที่ 2 - การทดสอบ
  • เราได้รับสิ่งประดิษฐ์จากขั้นตอนการสร้าง รันการทดสอบ รวบรวมข้อมูลความครอบคลุมของโค้ด
• ขั้นตอนที่ 3 - ส่ง
  • ภารกิจที่ 1 - สร้างแพ็คเกจ nuget และส่งไปยัง Azure DevOps
  • งาน 2 - เรารวบรวมไซต์จาก xmldoc ในซอร์สโค้ดและเผยแพร่ใน GitLab Pages

มาเริ่มกันเลย!

การรวบรวมการกำหนดค่า

การจัดทำบัญชี

1. สร้างบัญชีใน Microsoft Azure

2. ไปที่ Azure DevOps

3. เราสร้างโครงการใหม่

   1. ชื่อ - ใด ๆ
   2. ทัศนวิสัย - ใด ๆ
      

4. เมื่อคุณคลิกที่ปุ่มสร้าง โครงการจะถูกสร้างขึ้นและคุณจะถูกเปลี่ยนเส้นทางไปยังหน้าของมัน ในหน้านี้ คุณสามารถปิดใช้งานคุณลักษณะที่ไม่จำเป็นได้โดยไปที่การตั้งค่าโครงการ (ลิงก์ด้านล่างในรายการทางด้านซ้าย -> ภาพรวม -> บล็อก Azure DevOps Services)
   

5. ไปที่ Atrifacts คลิกสร้างฟีด

   1. ใส่ชื่อแหล่งที่มา
   2. เลือกการมองเห็น
   3. ยกเลิกการเลือก รวมแพ็คเกจจากแหล่งข้อมูลสาธารณะทั่วไปเพื่อให้แหล่งที่มาไม่กลายเป็นโคลนนักเก็ตดัมพ์
      

6. คลิก Connect to feed เลือก Visual Studio คัดลอก Source จากบล็อก Machine Setup
   

7. ไปที่การตั้งค่าบัญชี เลือกโทเค็นการเข้าถึงส่วนบุคคล
   

8. สร้างโทเค็นการเข้าถึงใหม่

   1. ชื่อ - โดยพลการ
   2. หน่วยงาน-ปัจจุบัน
   3. มีอายุใช้งานสูงสุด 1 ปี
   4. ขอบเขต - บรรจุภัณฑ์/อ่านและเขียน
      

9. คัดลอกโทเค็นที่สร้างขึ้น - หลังจากปิดหน้าต่างโมดอลแล้ว ค่าจะไม่สามารถใช้ได้

10. ไปที่การตั้งค่าที่เก็บใน GitLab เลือกการตั้งค่า CI / CD
    

11. ขยายบล็อกตัวแปร เพิ่มใหม่

    1. ชื่อ - ใด ๆ ที่ไม่มีช่องว่าง (จะมีอยู่ในเชลล์คำสั่ง)
    2. ค่า - โทเค็นการเข้าถึงจากวรรค 9
    3. เลือกตัวแปรมาสก์
       

เสร็จสิ้นการกำหนดค่าล่วงหน้า

กำลังเตรียมกรอบการกำหนดค่า

ตามค่าเริ่มต้น การกำหนดค่า CI/CD ใน GitLab จะใช้ไฟล์ .gitlab-ci.yml จากรากของที่เก็บ คุณสามารถกำหนดพาธไปยังไฟล์นี้ได้เองในการตั้งค่าที่เก็บ แต่ไม่จำเป็นในกรณีนี้

ดังที่คุณเห็นจากส่วนขยาย ไฟล์มีการกำหนดค่าในรูปแบบ YAML. เอกสารประกอบมีรายละเอียดว่าคีย์ใดบ้างที่สามารถมีได้ที่ระดับบนสุดของการกำหนดค่า และในแต่ละระดับที่ซ้อนกัน

ขั้นแรก ให้เพิ่มลิงก์ไปยังอิมเมจนักเทียบท่าในไฟล์การกำหนดค่า ซึ่งงานจะดำเนินการ สำหรับสิ่งนี้เราพบว่า หน้าอิมเมจ .Net Core บน Docker Hub. ใน GitHub มีคำแนะนำโดยละเอียดเกี่ยวกับภาพที่จะเลือกใช้สำหรับงานต่างๆ อิมเมจที่มี .Net Core 3.1 เหมาะสำหรับเราในการสร้าง ดังนั้นอย่าลังเลที่จะเพิ่มบรรทัดแรกในการกำหนดค่า

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

ตอนนี้ เมื่อเปิดไปป์ไลน์จากที่เก็บอิมเมจของ Microsoft อิมเมจที่ระบุจะถูกดาวน์โหลด ซึ่งงานทั้งหมดจากคอนฟิกูเรชันจะถูกดำเนินการ

ขั้นตอนต่อไปคือการเพิ่ม เวที's. ตามค่าเริ่มต้น 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. wtf?

ทุกอย่างมีเหตุผล - ตามค่าเริ่มต้น นักวิ่ง (รับผิดชอบในการเรียกใช้สคริปต์งานและจัดทำโดย 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 ใน GitLab CI/CD).

ลองนึกถึงข้อกำหนดชุดหนึ่ง - การประกอบและการทดสอบเฉพาะคำขอผสาน การบรรจุ และส่งไปยัง 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/*

เส้นทางรองรับสัญลักษณ์แทนซึ่งทำให้ตั้งค่าได้ง่ายขึ้น

หากงานสร้างสิ่งประดิษฐ์ แต่ละงานที่ตามมาจะสามารถเข้าถึงได้ - งานเหล่านั้นจะอยู่ในเส้นทางเดียวกันโดยสัมพันธ์กับรูทที่เก็บซึ่งรวบรวมจากงานดั้งเดิม สิ่งประดิษฐ์ยังมีให้ดาวน์โหลดบนเว็บไซต์

ตอนนี้เรามีโครงร่างการกำหนดค่าพร้อม (และทดสอบแล้ว) เราสามารถดำเนินการเขียนสคริปต์สำหรับงานจริงได้

เราเขียนสคริปต์

บางที กาลครั้งหนึ่งนานมาแล้ว ในกาแลคซีอันไกลโพ้น การสร้างโปรเจ็กต์ (รวมถึงโปรเจ็กต์บน .net) จากบรรทัดคำสั่งอาจเป็นเรื่องยุ่งยาก ตอนนี้คุณสามารถสร้าง ทดสอบ และเผยแพร่โครงการใน 3 ทีม:

dotnet build
dotnet test
dotnet pack

โดยธรรมชาติแล้วมีความแตกต่างบางประการเนื่องจากเราจะทำให้คำสั่งค่อนข้างซับซ้อน

1. เราต้องการ build รุ่น ไม่ใช่รุ่น debug เราจึงเพิ่มในแต่ละคำสั่ง -c Release
2. เมื่อทำการทดสอบ เราต้องการรวบรวมข้อมูลความครอบคลุมของโค้ด ดังนั้นเราจึงจำเป็นต้องรวมตัววิเคราะห์ความครอบคลุมไว้ในคลังทดสอบ:
   1. เพิ่มแพ็คเกจไปยังไลบรารีทดสอบทั้งหมด coverlet.msbuild: dotnet add package coverlet.msbuild จากโฟลเดอร์โครงการ
   2. เพิ่มในคำสั่งทดสอบการทำงาน /p:CollectCoverage=true
   3. เพิ่มคีย์ในการกำหนดค่างานทดสอบเพื่อให้ได้ผลลัพธ์ที่ครอบคลุม (ดูด้านล่าง)
3. เมื่อบรรจุโค้ดลงในแพ็กเกจ nuget ให้ตั้งค่าไดเร็กทอรีเอาต์พุตสำหรับแพ็กเกจ: -o .

การรวบรวมข้อมูลความครอบคลุมของรหัส

หลังจากรันการทดสอบ Coverlet จะพิมพ์สถิติการรันไปยังคอนโซล:

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 (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 Pages):
   1. สคริปต์:
      1. nuget install docfx.console -version 2.51.0 - ติดตั้ง docfx; มีการระบุเวอร์ชันเพื่อให้แน่ใจว่าพาธการติดตั้งแพ็คเกจถูกต้อง
      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 ในชื่อเรื่อง

ผลรวมย่อย

การกำหนดค่าที่เรียบง่ายดังกล่าวสามารถสร้างขึ้นได้ภายในเวลาเพียงครึ่งชั่วโมงและกาแฟสองสามแก้ว ซึ่งจะช่วยให้คุณสามารถตรวจสอบว่าโค้ดนั้นถูกสร้างขึ้นและผ่านการทดสอบแล้ว สร้างแพ็คเกจใหม่ อัปเดตเอกสารและโปรดตาด้วยความสวยงาม ป้ายชื่อใน README ของโครงการพร้อมคำขอผสานแต่ละรายการและส่งไปยังต้นแบบ

สุดท้าย .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

พูดถึงป้าย

เพราะพวกเขาทุกอย่างจึงเริ่มต้นขึ้น!

ป้ายที่มีสถานะไปป์ไลน์และการครอบคลุมโค้ดมีอยู่ใน GitLab ในการตั้งค่า CI/CD ในบล็อกไปป์ไลน์ Gtntral:

ฉันสร้างตราที่มีลิงก์ไปยังเอกสารประกอบบนแพลตฟอร์ม โล่.io - ทุกอย่างค่อนข้างตรงไปตรงมา คุณสามารถสร้างตราของคุณเองและรับโดยใช้คำขอ

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

Azure DevOps Artifact ยังช่วยให้คุณสร้างป้ายสำหรับแพ็คเกจด้วยเวอร์ชันล่าสุด ในการทำเช่นนี้ ในแหล่งที่มาบนไซต์ Azure DevOps คุณต้องคลิกสร้างตราสำหรับแพ็คเกจที่เลือกและคัดลอกมาร์กอัปมาร์กอัป:

เพิ่มความสวยงาม

เน้นส่วนการกำหนดค่าทั่วไป

ขณะที่เขียนการกำหนดค่าและค้นหาเอกสารประกอบ ฉันพบคุณลักษณะที่น่าสนใจของ YAML นั่นคือการนำชิ้นส่วนกลับมาใช้ใหม่

ดังที่คุณเห็นจากการตั้งค่างาน พวกเขาทั้งหมดต้องการแท็ก windows ที่รันเนอร์ และจะถูกทริกเกอร์เมื่อมีการส่งคำขอผสานไปยังมาสเตอร์/สร้าง (ยกเว้นเอกสารประกอบ) มาเพิ่มในส่วนที่เราจะใช้ซ้ำ:

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

และตอนนี้เราสามารถแทรกส่วนย่อยที่ประกาศไว้ก่อนหน้านี้ในรายละเอียดของงาน:

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

ชื่อแฟรกเมนต์ต้องขึ้นต้นด้วยจุด เพื่อไม่ให้ถูกตีความว่าเป็นงาน

การกำหนดเวอร์ชันของแพ็คเกจ

เมื่อสร้างแพ็คเกจ คอมไพลเลอร์จะตรวจสอบสวิตช์บรรทัดคำสั่ง และในกรณีที่ไม่มีไฟล์โครงการ เมื่อพบโหนดเวอร์ชัน ก็จะใช้ค่าเป็นเวอร์ชันของแพ็กเกจที่กำลังสร้าง ปรากฎว่าในการสร้างแพ็คเกจด้วยเวอร์ชันใหม่ คุณต้องอัปเดตในไฟล์โครงการหรือส่งเป็นอาร์กิวเมนต์บรรทัดคำสั่ง

มาเพิ่ม Wishlist อีกหนึ่งรายการ - ให้ตัวเลขรองสองตัวในเวอร์ชันเป็นปีและวันที่สร้างแพ็คเกจ และเพิ่มเวอร์ชันก่อนวางจำหน่าย แน่นอน คุณสามารถเพิ่มข้อมูลนี้ลงในไฟล์โครงการและตรวจสอบก่อนการส่งแต่ละครั้ง - แต่คุณสามารถทำได้ในไปป์ไลน์ รวบรวมเวอร์ชันแพ็คเกจจากบริบทและส่งผ่านอาร์กิวเมนต์บรรทัดคำสั่ง

ตกลงว่าหากข้อความยืนยันมีบรรทัดเช่น 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 และสังเกตการประกอบแพ็คเกจอย่างเคร่งครัดเมื่อมีสตริงที่กำหนดในข้อความยืนยัน

เบ็ดเสร็จ

หลังจากใช้เวลาประมาณครึ่งชั่วโมงหรือหนึ่งชั่วโมงในการเขียนคอนฟิกูเรชัน การดีบักใน PowerShell ในเครื่อง และการเปิดใช้ที่ไม่สำเร็จ XNUMX-XNUMX ครั้ง เราได้รับคอนฟิกูเรชันง่ายๆ สำหรับงานรูทีนโดยอัตโนมัติ

แน่นอนว่า GitLab CI / CD นั้นกว้างขวางและมีหลายแง่มุมมากกว่าที่คิดหลังจากอ่านคู่มือนี้ - นั่นไม่เป็นความจริงเลย. ที่นั่นด้วยซ้ำ Auto DevOps คืออนุญาต

ตรวจหา สร้าง ทดสอบ ปรับใช้ และตรวจสอบแอปพลิเคชันของคุณโดยอัตโนมัติ

ตอนนี้แผนคือการกำหนดค่าไปป์ไลน์สำหรับการปรับใช้แอปพลิเคชันกับ Azure โดยใช้ Pulumi และกำหนดสภาพแวดล้อมเป้าหมายโดยอัตโนมัติ ซึ่งจะกล่าวถึงในบทความถัดไป

ที่มา: will.com