복합 GitHub 작업을 통해 워크플로우를 더 작고 재사용 가능

작업 중에 어떤 사람들은 기존의 CI/CD 파이프라인을 Jenkins에서 GitHub 작업 흐름으로 옮겨서 개발자가 테스트, 기능과 생산 배치에 대해 더 많은 통제를 할 수 있도록 추진한다.
이 밖에 우리는 최근에 monorepo 구조로 전환하여 여러 응용 프로그램을 동시에 배치하기 위해 새로운 작업 흐름을 구축하고 있다.monorepo 구조를 사용한 결과 GitHub 작업 흐름의 크기와 용도가 각각 다르다.예를 들어 어떤 작업 흐름은 간단한 임무를 수행하는데 예를 들어 하나의 구성 요소에 대해 단원 테스트를 하고 다른 대형 작업 흐름은 완전한 생산 환경을 배치한다.
본고는 복합 GitHub 조작을 사용하여 작업 흐름을 더욱 작고 다시 사용할 수 있는 구성 요소로 나누는 방법을 보여 주는 데 목적을 둔다.

로컬 GitHub 작업
복합 작업에 대해 논의하기 전에 먼저 로컬 GitHub 작업에 대해 논의해야 합니다.일반적으로 GitHub 워크플로우를 만들면 Marketplace의 작업을 사용하지만, 시장에 발표하여 자신의 작업을 사용할 필요는 없습니다.로컬 GitHub 작업 use개를 저장소에 저장할 수 있다는 사실을 알고 계십니까?
로컬 작업은 같은 저장소에 저장된 다른 기초 구조 코드와 함께 유지보수할 수 있기 때문에 구성 요소화 GitHub 작업 흐름에 매우 적합하다.GitHub 워크플로우 .github/workflows의 .github/actions 디렉토리 옆에 저장하는 것은 좋지만 실제로는 저장소의 어느 곳에나 위치할 수 있습니다.
모든 사용자 정의 작업은 자신의 디렉터리와 action.yml으로 정의해야 한다.action.yml을 만들면 standard metadata을 추가하여 조작의 조작 방식을 정의할 수 있습니다.
워크플로에서 로컬 작업을 사용하려면 다음 구문을 사용하십시오(.github/actions 디렉토리에 사용자 정의 작업을 저장한 경우).

jobs:
  run-local-action:
    steps:
      # Checkout the repository first
      # Otherwise the workflow won't be able to find the action
    - use: actions/checkout@v2
    - name: Run custom action
      # Use the location in the repository (without action.yml)
      uses: ./.github/actions/my-custom-action
      with:
        custom-input: 10

로컬 작업은 GitHub 작업을 만드는 데 아주 좋은 방법으로 사용자가 원하는 방식에 따라 맞춤형 작업을 할 수 있으며 다른 제품의 발표를 관리할 필요가 없습니다.

복합 작용
복합 작업은 만들 수 있는 three different types custom GitHub Actions(복합, JavaScript 및 Docker) 중 하나입니다.주요 차이점은 복합 조작의 action.yml -> runs 속성은 실행할 프로그램의 목록이 아니라 실행할 프로그램의 목록을 포함한다는 것이다.

runs:
  using: "composite"
  steps:

steps 부분의 작용은 거의 steps section in a workflow과 완전히 같지만 약간의 차이는 뒤에 개술할 것이다.
로컬 복합 GitHub 만들기 작업은 GitHub 워크플로우를 분할하는 완벽한 방법으로 보입니다!

너는 너의 업무 절차를 복합 동작으로 분해해야 합니까?
몇 주 동안 복합 동작을 사용한 후에 나는 네가 반드시 그것들을 사용해야 한다고 생각한다. 왜냐하면 그것들은 더욱 작고 읽을 수 있는 작업 흐름을 초래했기 때문이다. 왜냐하면 모든 동작은 특정한 목적을 가지고 있기 때문이다.
다음은 업무 흐름에서 복합 조작을 사용하는 장점과 한계를 추가했다.

우세하다

대규모 워크플로우를 여러 파일로 분리

다중 워크플로우를 위한 구성 요소 작업 만들기 - 중복 감소

GitHub의 Actions 보기에서 여러 단계가 하나의 단계로 압축되어 워크플로우 진행률

을 추적하는 능력이 향상되었습니다.

은 필요한 입력과 출력을 이해할 때 action.yml 파일의 묘사성이 GitHub 작업 흐름의 가독성을 향상시켰다.

제한성

그들은 GitHub의 비밀을 이해하지 못한다.

에서 그것을 전달해야 한다.

은 작은 번거로움에도 불구하고 단계별로 shell을 정의해야 한다.

예.
배포 노드가 있는 GitHub 워크플로우를 가정합니다.js/Express API 및 AWS S3용 React 응용 프로그램다음과 같이 저장소의 .github/workflows/deploy-app.yml에 저장됩니다.

name: Deploy app
on:
  pull_request:
jobs:
  deploy-api:
    outputs:
      # Output the deployed API URL for consumption later
      url: ${{ steps.deploy.output.url }}
    steps:
      - uses: actions/checkout@v2
      # ...more steps to deploy an API and output a URL
  deploy-frontend:
    name: Deploy frontend to AWS S3
    needs: deploy-api
    steps:
      - uses: actions/checkout@v2
      - uses: aws-actions/configure-aws-credentials@v1
        with:
          # Always store tokens in a secret manager. Here I am using GitHub Secrets
          aws-access-key-id: ${{ secrets.AWS_ACCESS_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
          aws-region: eu-west-1
      - uses: actions/setup-node@v2
        with:
          node-version: 14
      - name: Install dependencies
        working-directory: ./frontend
        run: npm ci
      - name: Build app
        working-directory: ./frontend
        run: npm run build
        env:
          APP_NAME: Demo
          API_URL: ${{ needs.deploy-api.outputs.url }}
      - name: Upload app to AWS S3
        working-directory: ./frontend
        run: aws s3 sync build s3://my-bucket --delete

이 작업 흐름 자체는 상대적으로 작고 읽을 수 있지만, 다른 프로그램을 추가해서 배치하거나, 더 복잡한 전단 배치일 경우, 비대해지고 읽기 어려워질 수 있다고 상상해 보세요.
이 워크플로우를 한층 더 검증하기 위해 frontend-deploy 작업의 대부분을 하나의 복합 작업으로 통합할 수 있습니다.

사용자 정의 작업 파일 만들기
우선, 우리는 디렉터리와 action.yml을 만듭니다.앞에서 말한 바와 같이 사용자 정의 조작을 .github/actions 디렉터리에 저장하는 것은 일치한다.따라서 내 deploy-frontend-to-s3 작업은 .github/actions/deploy-frontend-to-s3/action.yml으로 저장되어 다음과 같은 저장소 구조를 제공합니다.

.github
  - workflows
    - deploy-app.yml
  - actions
    - deploy-api/action.yml
    - deploy-frontend-to-s3/action.yml

deploy-frontend-to-s3 복합 작업 수행
현재 action.yml 파일을 만들었습니다. deploy-frontend 작업의 많은 절차를 작업 흐름에서 작업 흐름으로 옮길 수 있습니다.
먼저 name, description 및 inputs을 action.yml에 추가할 수 있습니다.

name: "Deploy Frontend to S3"
description: "Builds and deploys the React frontend to AWS S3"
inputs:
   aws-access-key-id:
     required: true
     description: "The aws-access-key-id used to authenticate with AWS"
   aws-secret-access-key:
     required: true
     description: "The aws-secret-access-key used to authenticate with AWS"
   app-name:
     required: false
     description: "The app name used by the React app"
     default: Demo
   api-url:
     required: true
     description: "The URL of the Express app"

그런 다음 이전에 워크플로우에 있었던 명령을 실행하는 작업의 일부를 만들 수 있습니다.우리는 어떻게 ${{ inputs.input-name }}을 사용하여 상술한 입력을 참고하는지 주의하십시오.

# ...name, description and inputs as above
runs:
  using: "composite"
  steps:
    - uses: aws-actions/configure-aws-credentials@v1
      with:
        # Actions cannot access secrets so pass them in as inputs
        aws-access-key-id: ${{ inputs.aws-access-key-id }}
        aws-secret-access-key: ${{ inputs.aws-secret-access-key }}
        aws-region: eu-west-1
    - uses: actions/setup-node@v2
      with:
        node-version: 14
    - name: Install dependencies
      working-directory: ./frontend
      run: npm ci
    - name: Build app
      working-directory: ./frontend
      run: npm run build
      env:
        APP_NAME: ${{ inputs.app-name }}
        API_URL: ${{ inputs.api-url }}
    - name: Upload app to AWS S3
      working-directory: ./frontend
      run: aws s3 sync build s3://my-bucket --delete

steps 부분은 거의 작업 흐름 steps 부분의 복사와 붙여넣기입니다.유일하게 부족한 부분은 actions/checkout입니다. GitHub이 로컬 작업에 접근할 수 있도록 작업 흐름에 있어야 하기 때문입니다.
deploy-app 워크플로의 사용자 지정 작업 사용
이제 워크플로에서 사용할 수 있는 사용자 정의 작업이 구축되었습니다.

name: Deploy app
on:
  pull_request:
jobs:
  deploy-api:
    outputs:
      # Output the deployed API URL for consumption later
      url: ${{ steps.deploy.output.url }}
    steps:
      - uses: actions/checkout@v2
      -  id: deploy
         uses: ./.github/actions/deploy-api
  deploy-frontend:
    name: Deploy frontend to AWS S3
    needs: deploy-api
    steps:
      - uses: actions/checkout@v2
      - name: Deploy frontend
        # Directory name only
        uses: ./.github/actions/deploy-frontend-to-s3
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
          # won't pass in app-name as it's defaulted to "Demo"
          api-url: ${{ needs.deploy-api.outputs.url }}

우리 망했어!deploy-app 워크플로우의 크기를 줄이고 S3에 전면 배포를 위한 재사용 가능한 복합 작업을 수행했습니다.

작업 디렉토리의 파일 사용
복합 동작을 만들 때, action.yml에서 사용하는 유틸리티 파일을 만들어야 할 수도 있습니다.이 동작을 실행할 때 ${{ github.action_path }} 변수를 사용하여 인용해야 합니다. 이렇게 하면 다시 위치를 정하면 경로를 업데이트할 필요가 없습니다.
따라서 .github/actions/deploy-frontend-to-s3/fetch-bucket-name.sh이라는 파일을 작업에서 ${{ github.action_path }}/fetch-bucket-name.sh이라고 할 수 있다.

포위하여 체포하다
본고에서 나는 복합조작이 GitHub 작업 흐름을 더욱 작은 소비 가능한 구성 요소로 분해하는 데 어떻게 도움을 주는지 설명하고 이렇게 하는 장점을 설명했다.
당신은 업무 중에 방대한 업무 절차를 처리하고 있습니까? 아니면 이미 복합 동작을 사용하고 있습니까?아래의 평론에서 저에게 알려주세요.
만약 이 문장이 너에게 도움이 된다면, 어떠한 반응도 하지 마라.
읽어주셔서 감사합니다!