Github 작업을 사용하여 동적 CI/CD 파이프를 설정하는 방법

트위터에서 저를 팔로우해 주세요. 구독Newsletter | 최초로 timdeschryver.dev에 발표되었습니다.
Read the TLDR version on timdeschryver.dev
Github가 발표되었을 때, 나는 Github 작업 흐름을 사용하기 위해 대부분의 CI/CD 파이프를 이동했다.프로젝트마다 두 개의 작업 흐름이 있는데, 한 작업 흐름은 당김 요청에서 실행되고, 다른 작업 흐름은 누군가가 제출을 main 지점으로 보낼 때 터치된다.이 두 작업 흐름은 거의 같은 복사본이다. main 분기 작업 흐름은 발표 절차의 부분을 포함한다.
현재 중요한 1년이 지난 후에 나는 내가 처리하고 있는 몇 가지 프로젝트의 작업 흐름이 작업 흐름 중의 일부 절차를 조건적으로 설정했다는 것을 알아차렸다.나는 확실하지 않지만, 나는 상황이 항상 그렇지는 않다고 생각한다.또는 처음에 워크플로우 파이프라인을 설정했을 때 문서에서 이러한 가능성을 완전히 무시했습니다.
왜 나는 이것이 매우 중요하다고 생각합니까?
하나의 워크플로만 중복을 방지할 수 있으므로 새 버전의 노드를 사용하는 등 워크플로를 쉽게 변경할 수 있습니다.js, 또는 추가 절차를 추가합니다.
그래서 나는 두 개의 업무 흐름을 하나의 업무 흐름으로 통합하는 데 시간이 좀 걸렸다.
이를 위해 나는 몇 번의 교체와 많은 실패의 구축이 필요하다. 이것이 바로 내가 그것에 관한 작은 글을 쓰기로 결정한 이유이다.우리가 최종적으로 사용하는 작업 흐름은 요청 당기는 동안 여러 환경에서 실행되고 요청이 main 지점에 통합될 때 조건 해제 절차를 포함한다.
우리 뛰어들어가자!

Github 작업 워크플로우 실행 시기 결정

작업 흐름을 실행하려면 트리거를 정의해야 합니다.
내 예에서, 나는 작업 흐름이 push 지점이 발생할 때 main 실행되고, 요청을 열거나 변경할 때 실행되기를 바란다.

name: ci

on:
  push:
    branches:
      - 'main'
  pull_request: {}

워크플로의 작업

다음에 우리는 작업 흐름의 임무를 정의해야 한다.
이것은 실행 jobs 을 포함하는 하나 이상의 steps 을 추가함으로써 이루어진 것이다.
간단한 CI/CD 파이프라인에서 나는 한 가지 일만 하는 것을 더 좋아한다. 왜냐하면 그것은 더욱 간단하기 때문이다.
여러 개의 작업을 포함하는 프로젝트를 처리하고 있다면, 여러 개의 작업을 정의하는 것이 좋습니다. 이 작업들은 병렬적으로 실행되기 때문에 실행 시간이 더 짧습니다.
작업은 실행해야 할 runs-on를 포함하는 운영 환경이 필요합니다.
노드의 워크플로우입니다.js 프로젝트는 다음 작업 흐름처럼 보일 수 있으며 프로젝트를 구축하고 테스트하며 발표하는 데 사용됩니다.

name: ci

on:
  push:
    branches:
      - 'main'
  pull_request: {}

jobs:
  build_test_release:
    runs-on: 'ubuntu-latest'

    steps:
      - uses: actions/checkout@v2
      - name: use Node.js
        uses: actions/setup-node@v2
      - name: install
        run: npm install
      - name: build
        run: npm run build
      - name: test
        run: npm run test
      - name: Release
        run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

그러나 위의 작업 흐름에 문제가 하나 있다. 바로 steps 절차다.
워크플로가 실행될 때마다 코드가 게시됩니다.이 작업 흐름도 요청에서 실행되기 때문에, 이것은 우리가 필요하지 않은 버전을 발표할 것을 의미한다.

조건부 단계

복구로 우리는 를 사용하여 발표 절차를 조건부로 실행할 수 있다.
이 복구 프로그램은 발표 절차가 Release 지점에서만 호출되고, 저희 저장소에서 실행될 때만 호출될 수 있도록 합니다.
두 번째 검사는 분기 저장소의 의외의 버전 발표를 방지하기 위한 안전 예방 조치이다.

name: ci

on:
  push:
    branches:
      - 'main'
  pull_request: {}

jobs:
  build_test_release:
    runs-on: 'ubuntu-latest'

    steps:
      - uses: actions/checkout@v2
      - name: use Node.js
        uses: actions/setup-node@v2
      - name: install
        run: npm install
      - name: build
        run: npm run build
      - name: test
        run: npm run test
      - name: Release
        run: npx semantic-release
        if: github.ref == 'refs/heads/main' && github.repository == 'REPO_OWNER/REPO_NAME'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

지금까지는 괜찮았습니다. 이 작업 절차는 당신의 모든 수요를 만족시킬 수 있습니다.

하면, 만약, 만약... 여러 환경에서 실행

만약 당신이 일을 새로운 수준으로 향상시키고 싶다면, 여러 환경과 여러 노드에서 운행하도록 작업 흐름을 조정할 수 있다.js 버전.
이것이 바로 나의 관점이 사람들의 흥미를 끄는 부분이다. 왜냐하면 다른 공헌자와 사용자가 환경에 특정한 문제를 겪지 않도록 확보하기 때문이다.
서로 다른 환경을 정의하기 위해서, 우리는 를 사용하고, 서로 다른 버전을 하나의 그룹으로 지정합니다.이 그룹은 작업 흐름에서 사용할 수 있는 사용자 정의 변수에 분배됩니다.
작업 중의 모든 절차는 행렬의 가능한 모든 조합에 맞추어 운행된다.다음 예에서, 이것은 모든 단계가 모두 여섯 번 실행된다는 것을 의미한다. 예를 들어 ubuntu와 Node에서 한 번 실행된다는 것이다.js 버전 12, 다른 것은 윈도우즈와 노드에 있습니다.js 버전 12.

name: ci

on:
  push:
    branches:
      - 'main'
  pull_request: {}

jobs:
  build_test_release:
    strategy:
      matrix:
        node-version: [12, 14, 16]
        os: ['ubuntu-latest', 'windows-latest']
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v2
      - name: use Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
      - name: install
        run: npm install
      - name: build
        run: npm run build
      - name: test
        run: npm run test
      - name: Release
        run: npx semantic-release
        if: github.ref == 'refs/heads/main' && github.repository == 'REPO_OWNER/REPO_NAME'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

하지만 예전처럼 함정이 하나 있다.main 지점으로 보내면 석방도 6번 촉발된다.결과는 여섯 차례 발표되었다.
노드를 포함하도록 표현식을 확장할 수 있습니다.js버전과os버전,하지만 더 좋은 방법이 있습니다.

정책 매트릭스 구문 동적 버전

여러 번 작업 흐름을 실행하는 데 시간이 좀 걸릴 수 있습니다. 통합 추출 요청을 한 후에 전체 구축 과정을 다시 실행할 필요가 없다고 생각합니다.만약pull 요청이 녹색이라면, 코드가 발표될 준비가 되어 있다고 가정할 수 있습니다.다시 말하면 main 지점의 작업 흐름이 촉발될 때 우리는 행렬을 필요로 하지 않는다.if 지점에서 작업 흐름을 완성하는 데 필요한 시간을 줄이기 위해 우리는 행렬에 버전을 하나만 추가할 수 있습니다.
이러한 워크플로우 변경으로 인해 여러 버전의 문제가 해결되었습니다.
이를 실현하기 위해 우리는 동태적으로 행렬을 구축할 수 있다.main를 사용하여 현재 지점의 상하문에 검사를 추가하면 우리는 조건부로 그룹을 정의할 수 있다.
이 기술은 수조를 문자열로 정의하고 을 사용하여 우리가 작업 흐름에서 사용할 수 있는 실제 수조로 변환하는 것이다.

name: ci

on:
  push:
    branches:
      - 'main'
  pull_request: {}

jobs:
  build_test_release:
    strategy:
      matrix:
        node-version: ${{ fromJSON(github.ref == 'refs/heads/main' && '[16]' || '[12,14,16]') }}
        os: ${{ fromJSON(github.ref == 'refs/heads/main' && '["ubuntu-latest"]' || '["ubuntu-latest", "windows-latest"]') }}
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v2
      - name: use Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
      - name: install
        run: npm install
      - name: build
        run: npm run build
      - name: test
        run: npm run test
      - name: Release
        run: npx semantic-release
        if: github.ref == 'refs/heads/main' && github.repository == 'REPO_OWNER/REPO_NAME'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

주요 방법 최종 결과

봐라, 우리는 현재 단일한 작업 흐름이 하나 있는데, 그것은 상하문을 고려하여 작업 흐름의 정확한 절차를 가동시켰다.
Pull 요청에서 코드는 여러 환경에서 테스트를 진행하여 버전을 발표하는 데 필요한 모든 신뢰를 제공합니다.
푸시github.ref 분기는 특정한 환경에서만 작업 흐름을 운행하고 조건 해제 절차를 포함한다.

결론

코드는 한 라이브러리의 여러 버전으로 테스트를 해서 향후 호환성을 확보할 수 있기 때문에 미래의 동적 작업 흐름이 무엇을 가져올지 보고 매우 기쁩니다.반드시 수동으로 이 일을 완성해야 하기 때문에 대량의 일이 필요하며, 심지어는 불가능할 수도 있다.
예를 들어 서로 다른 ESLint 버전의 서로 다른 ESLint 규칙과 eslint-plugin-testing-library pipeline 여러 버전에서 작업 흐름을 실행하는 GitHub 작업을 테스트합니다.얼마나 깔끔한가!
트위터에서 저를 팔로우해 주세요. 구독angular-versions-action | 최초로 Newsletter에 발표되었습니다.