(거의) 완전 초보자를 위한 GitLab의 CI/CD 가이드

또는 쉬운 코딩의 하루 저녁에 프로젝트에 대한 아름다운 배지를 얻는 방법

아마도 어느 시점에서 적어도 하나의 애완 프로젝트를 가지고 있는 모든 개발자는 상태, 코드 커버리지, nuget의 패키지 버전이 있는 아름다운 배지에 대한 가려움증을 가지고 있을 것입니다. 그리고 이 가려움증으로 인해 이 기사를 작성하게 되었습니다. 그것을 작성하기 위한 준비로, 나는 내 프로젝트 중 하나에서 이 아름다움을 얻었습니다.

이 문서에서는 GitLab의 .Net Core 클래스 라이브러리 프로젝트에 대한 지속적인 통합 및 제공의 기본 설정, GitLab Pages에 문서 게시, 빌드된 패키지를 Azure DevOps의 프라이빗 피드로 푸시하는 과정을 안내합니다.

VS Code는 확장 기능이 있는 개발 환경으로 사용되었습니다. GitLab 워크플로우 (개발 환경에서 직접 설정 파일의 유효성을 검사하기 위해).

간단한 소개

CD-방금 밀었을 때 모든 것이 이미 클라이언트에 떨어졌습니까?

CI / CD 란 무엇이며 왜 필요한지 Google에서 쉽게 찾을 수 있습니다. GitLab에서 파이프라인 구성에 대한 전체 문서 찾기 또한 쉽게. 여기에서는 조감도에서 시스템 프로세스를 간략하게 설명하고 가능한 경우 결함없이 설명합니다.

• 개발자는 저장소에 커밋을 보내고, 사이트를 통해 병합 요청을 만들고, 또는 다른 방식으로 명시적 또는 암시적으로 파이프라인을 시작합니다.,
• 모든 작업은 구성에서 선택되며 해당 조건은 주어진 컨텍스트에서 시작할 수 있습니다.
• 작업은 단계에 따라 구성되며,
• 단계가 차례로 실행됩니다. 평행선 이 단계의 모든 작업이 완료되고
• 단계가 실패하면(즉, 단계의 작업 중 하나 이상이 실패하면) 파이프라인이 중지됩니다(거의 언제나),
• 모든 단계가 성공적으로 완료되면 파이프라인이 성공한 것으로 간주됩니다.

따라서 우리는 다음을 갖습니다:

• 파이프라인 - 코드를 빌드, 테스트, 패키징하고 완성된 빌드를 클라우드 서비스에 배포할 수 있는 단계로 구성된 일련의 작업
• 단계 (단계) — 파이프라인 구성 단위, 1개 이상의 작업 포함,
• 일 (일)는 파이프라인의 작업 단위입니다. 스크립트(필수), 시작 조건, 아티팩트 게시/캐싱 설정 등으로 구성됩니다.

따라서 CI/CD를 설정할 때 작업은 코드 및 아티팩트를 빌드, 테스트 및 게시하는 데 필요한 모든 작업을 구현하는 일련의 작업을 만드는 것으로 귀결됩니다.

시작하기 전에: 왜?

• 왜 Gitlab인가?

펫 프로젝트를 위한 개인 리포지토리를 만들어야 할 때 깃허브에서 돈을 받고 욕심을 냈기 때문입니다. 리포지토리는 무료가 되었지만 지금까지는 GitHub로 이동할 이유가 충분하지 않습니다.

• Azure DevOps 파이프라인이 아닌 이유는 무엇입니까?

설정이 기본이기 때문에 명령줄에 대한 지식도 필요하지 않습니다. 외부 git 공급자와의 통합 - 몇 번의 클릭만으로 SSH 키를 가져와 커밋을 리포지토리로 보낼 수 있습니다. 파이프라인은 템플릿이 아니더라도 쉽게 구성할 수 있습니다.

시작 위치: 가지고 있는 것과 원하는 것

우리는 :

• GitLab의 저장소.

우리는 원합니다:

• 각 병합 요청에 대한 자동 조립 및 테스트
• 커밋 메시지에 특정 줄이 있는 경우 각 병합 요청에 대한 패키지를 빌드하고 마스터로 푸시합니다.
• 빌드된 패키지를 Azure DevOps의 비공개 피드로 전송,
• GitLab 페이지에서 문서 및 게시의 조립,
• 배지!11

설명된 요구 사항은 유기적으로 다음 파이프라인 모델에 속합니다.

• 1단계 - 조립
  • 코드를 수집하고 출력 파일을 아티팩트로 게시합니다.
• 2단계 - 테스트
  • 빌드 단계에서 아티팩트를 가져오고, 테스트를 실행하고, 코드 커버리지 데이터를 수집합니다.
• 3단계 - 제출
  • 작업 1 - nuget 패키지를 빌드하고 Azure DevOps로 보냅니다.
  • 작업 2 - 소스 코드의 xmldoc에서 사이트를 수집하고 GitLab 페이지에 게시합니다.

시작하자!

구성 수집

계정 준비

1. 에서 계정 만들기 Microsoft Azure

2. 우리는에 전달한다. 애저 데브옵스

3. 우리는 새로운 프로젝트를 만듭니다

   1. 이름 - 아무거나
   2. 가시성 - 모두
      

4. 만들기 버튼을 클릭하면 프로젝트가 생성되고 해당 페이지로 리디렉션됩니다. 이 페이지에서 프로젝트 설정으로 이동하여 불필요한 기능을 비활성화할 수 있습니다(왼쪽 목록의 하단 링크 -> 개요 -> Azure DevOps Services 블록).
   

5. Atrifacts로 이동하여 피드 만들기를 클릭합니다.

   1. 소스 이름을 입력하세요.
   2. 가시성 선택
   3. 체크 해제 공통 공개 소스의 패키지 포함, 소스가 덤프 너겟 클론으로 바뀌지 않도록
      

6. 피드에 연결을 클릭하고, Visual Studio를 선택하고, Machine Setup 블록에서 소스를 복사합니다.
   

7. 계정 설정으로 이동하여 개인 액세스 토큰을 선택하십시오.
   

8. 새 액세스 토큰 만들기

   1. 이름 - 임의
   2. 조직 - 현재
   3. 최대 1년 동안 유효
   4. 범위 - 패키징/읽기 및 쓰기
      

9. 생성된 토큰 복사 - 모달 창이 닫힌 후에는 값을 사용할 수 없습니다.

10. GitLab의 리포지토리 설정으로 이동하여 CI/CD 설정을 선택합니다.
    

11. Variables 블록을 확장하고 새 블록을 추가하십시오.

    1. 이름 - 공백 없음(명령 셸에서 사용 가능)
    2. 값 - 단락 9의 액세스 토큰
    3. 마스크 변수 선택
       

이렇게 하면 사전 구성이 완료됩니다.

구성 프레임워크 준비

기본적으로 GitLab의 CI/CD 구성은 파일을 사용합니다. .gitlab-ci.yml 저장소의 루트에서. 저장소 설정에서 이 파일에 대한 임의의 경로를 설정할 수 있지만 이 경우에는 필요하지 않습니다.

확장에서 볼 수 있듯이 파일에는 다음 형식의 구성이 포함되어 있습니다. YAML. 설명서에는 구성의 최상위 수준과 각 중첩 수준에 포함할 수 있는 키가 자세히 설명되어 있습니다.

먼저 작업을 수행할 구성 파일의 도커 이미지에 대한 링크를 추가해 보겠습니다. 이를 위해 우리는 Docker Hub의 .Net Core 이미지 페이지. 에 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 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. 우리는 디버그 빌드가 아닌 릴리스 빌드를 원하므로 각 명령에 추가합니다. -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.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 - 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 이름으로

소계

이러한 간단한 구성은 코드가 작성되고 테스트가 통과하는지 확인하고, 새 패키지를 작성하고, 문서를 업데이트하고, 아름답게 눈을 즐겁게 할 수 있는 커피 몇 잔과 XNUMX분이면 만들 수 있습니다 각 병합 요청과 함께 프로젝트의 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

배지에 대해 말하면

그들로 인해 결국 모든 것이 시작되었습니다!

파이프라인 상태 및 코드 적용 범위가 있는 배지는 Gtntral 파이프라인 블록의 CI/CD 설정에 있는 GitLab에서 사용할 수 있습니다.

플랫폼의 문서에 대한 링크가 있는 배지를 만들었습니다. Shields.io - 모든 것이 매우 간단합니다. 나만의 배지를 만들고 요청을 사용하여 받을 수 있습니다.

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

Azure DevOps Artifacts를 사용하면 최신 버전의 패키지에 대한 배지를 만들 수도 있습니다. 이렇게 하려면 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 커밋 메시지에 주어진 문자열이 있는 경우 패키지 어셈블리를 엄격하게 관찰합니다.

전체로

약 XNUMX분 또는 XNUMX시간 동안 구성을 작성하고, 로컬 powershell에서 디버깅하고, 아마도 몇 번의 실행 실패를 겪은 후 일상적인 작업을 자동화하기 위한 간단한 구성을 얻었습니다.

물론 GitLab CI/CD는 이 가이드를 읽은 후 보이는 것보다 훨씬 더 광범위하고 다면적입니다. 완전히 잘못 됐어.. 거기에도 자동 DevOps는허용

애플리케이션을 자동으로 감지, 빌드, 테스트, 배포 및 모니터링

이제 계획은 Pulumi를 사용하고 다음 문서에서 다룰 대상 환경을 자동으로 결정하여 Azure에 애플리케이션을 배포하기 위한 파이프라인을 구성하는 것입니다.

출처 : habr.com