ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Github Action이란
    저장소/git 2022. 1. 29. 19:35

    github repository가 있다면 github action을 사용하여 workflow를 구성할 수 있습니다.

    workflow의 예시는 다음과 같습니다.

    1. test code 실행
    2. 배포
    3. 자동화 하고자 하는 스크립트
    4. 파이썬 버전 실행 여부 확인

    가격은 아래와 같이 다양하지만 대규모 프로젝트가 아닌 이상 무료버전으로도 충분히 사용할 수 있어 보입니다.

    github action 이해하기

    GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼입니다. repository에 대한 모든 pull request를 빌드 및 테스트하는 workflow를 생성하거나 병합된 pull request를 프로덕션에 배포할 수 있습니다.

    GitHub Actions는 단순한 DevOps를 넘어 repository에서 다른 이벤트가 발생할 때 workflow를 실행할 수 있도록 합니다. 예를 들어, 누군가가 저장소에 새로운 이슈를 생성할 때마다 적절한 레이블을 자동으로 추가하는 workflow를 실행할 수 있습니다.

    GitHub은 workflow를 실행하기 위한 Linux, Windows 및 macOS 가상 머신을 제공하거나 자체 데이터 센터 또는 클라우드 인프라에서 자체 호스팅 러너를 호스팅할 수 있습니다.

    컴포넌트

    pull request가 열리거나 이슈가 생성되는 것과 같은 이벤트가 repository에서 발생할 때 트리거되도록 GitHub workflow를 구성할 수 있습니다. workflow에는 순차적으로 또는 병렬로 실행할 수 있는 하나 이상의 job이 포함되어 있습니다. 각 job은 자체 가상 머신 runner 내부 또는 컨테이너 내부에서 실행되며, 사용자가 정의한 스크립트를 실행하거나 job을 실행하는 하나 이상의 단계(워크플로를 단순화할 수 있는 재사용 가능한 확장)가 있습니다.

    workflows

    workflow는 하나 이상의 job으로 구성되고 event에 의해 트리거될 수 있는 자동화된 프로세스입니다. 가장 최상위 개념으로 YAML으로 작성되고 Github Repository의 .github/workflows 폴더 아래에 저장합니다. repository에는 여러 workflow를 가질 수 있으며 각 workflow는 서로 다른 작업을 수행할 수 있습니다.

    events

    event는 workflow 실행을 트리거하는 특정 활동이나 규칙입니다. 예를 들어, 누군가가 pull request를 생성하거나 issue를 열거나 특정 브랜치로 push하거나 특정 시간대에 반복(cron)하거나 webhook을 사용해 외부 이벤트를 통해 실행될 수 있습니다.

    jobs

    jobs은 여러 step으로 구성되고 가상 환경의 인스턴스에서 실행됩니다. 다른 job에 의존 관계를 가질 수 있고 독립적으로 병렬 실행도 가능합니다.

    • Workflow는 다양한 Job으로 구성되는데 기본적으로 병렬로 실행

    steps

    step은 task들의 집합으로 커맨드를 날리거나 쉘 스크립트 실행하는 것처럼 action을 실행할 수 있습니다.

    actions

    workflow의 가장 작은 블럭으로 job을 만들기 위해 step들을 연결할 수 있습니다. 재사용이 가능한 컴포넌트로서 반복적인 코드의 양을 줄일 수 있고 git repository를 가져오거나 클라우드 공급자에게 인증을 설정할 수도 있습니다. 또한 개인적으로 만든 action을 작성할 수도 있고 github marketplace에 있는 공용 action을 사용할 수도 있습니다.

    runners

    runner는 workflow가 트리거될 때 실행하는 서버입니다. 각 runner는 1번에 1개의 job을 실행할 수 있습니다. Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉩니다. Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB입니다.

    생성 예시

    GitHub Actions는 YAML 구문을 사용하여 워크플로를 정의합니다. 각 워크플로는 .github/workflows라는 디렉터리의 코드 repository에 별도의 YAML 파일로 저장됩니다.

    직접 작성할 수도 있지만 아래와 같이 템플릿을 활용하면 좋습니다.

    Configure 버튼을 누르면 쉽게 workflow를 생성할 수 있습니다.

    workflow 파일 내 컴포넌트 이해하기

    name: CI
    
      on:
        push:
          branches: [ master ]
        pull_request:
          branches: [ master ]
    
      jobs:
        build:
          runs-on: ubuntu-latest
    
          steps:
          - uses: actions/checkout@v2
    
          - name: Run a one-line script
            run: echo Hello, world!
    
          - name: Run a multi-line script
            run: |
              echo Add other actions to build,
              echo test, and deploy your project.

    master 브랜치에 Push 또는 Pull Request가 올 경우 실행되는 CI란 이름을 갖는 Workflow 파일입니다.

    name

    CI란 이름으로 GitHub repository의 작업 탭에 표시될 워크플로의 이름으로 작성을 하지 않아도 됩니다.

    on

    workflow에 대한 트리거를 지정합니다. 위의 예시에서는 push와 pull request가 master 브랜치에 있는데 누군가가 변경사항을 master 브랜치에 push하거나 pull request 할 경우, workflow 실행이 트리거 됩니다. 이는 어레이로 여러 브랜치를 설정할 수도 있고 브랜치가 아닌 특정 파일, 스케쥴도 설정할 수 있습니다.

    jobs

    CI workflow에서 실행되는 모든 job들을 그룹화합니다.

    build

    build라는 이름의 job을 생성합니다. 그 하위에는 2개의 step이 존재하는 구조입니다.

    runs-on

    runs-on은 어떤 OS에서 실행될지 지정하는 곳입니다. 위 예제에서는 ubuntu 최신 버전에서 실행하도록 합니다.

    steps

    build 작업에서 실행되는 모든 steps를 그룹화합니다. 이 섹션 하위에 중첩된 각 항목은 별도의 작업이거나 셸 스크립트입니다.

    - uses

    uses 키워드는 이 단계에서 actions/checkout@/v2 를 실행하도록 지정합니다. 이것은 내 repository를 runner에서 체크아웃하여 스크립트 또는 빌드 및 테스트 도구를 실행할 수 있도록 하는 작업입니다. repository의 코드에 대해 workflow가 실행될 때마다 checkout 작업을 사용해야 합니다.

    - name

    해당 step의 이름을 명시합니다.

    - run

    run 키워드는 runner에서 command를 실행하도록 지시합니다. 여기에는 환경변수를 설정할 수도 있습니다.

    위와 같이 저장을 한다면 아래 예시처럼 시각화된 workflow를 볼 수 있습니다.

    workflow 관리

    민감 정보 저장하고 사용하기

    민감한 정보 사용해야된다면 Github > Settings > secrets 에 저장하여 환경변수로 사용할 수 있습니다.

    jobs:
      example-job:
        runs-on: unbuntu-latest
        steps:
          - name: test secret key
            env:
              secret_key: ${{ secrets.SUPERSECRET }}
            run: |
              ~~~ "$secret_key"

    job의 의존 관계 설정하기

    job 끼리 의존 관계를 설정해 순서를 정의할 수 있습니다.

    jobs:
      job1:
      job2:
        needs: job1
      job3:
        needs: [job1, job2]

    job1은 job2이 시작되기 전에 성공적으로 완료되어야 하고 job3은 job1과 job2이 모두 완료될 때까지 기다립니다.

    jobs:
      setup:
        runs-on: ubuntu-latest
        steps:
          - run: ./setup.sh
      build:
        needs: setup
        runs-on: ubuntu-latest
        steps:
          - run: ./build.sh
      test:
        needs: build
        runs-on: ubuntu-latest
        steps:
          - run: ./test.sh

    setup 실행, 성공하면 build가 실행되고 성공하면 test가 실행됩니다.

    여러 버전으로 실행하기

    다양한 OS, 플랫폼, 언어의 여러 조합에서 테스트를 실행하려는 경우 빌드 매트릭스를 활용하면 됩니다. 빌드 옵션을 배열로 받는 strategy 키워드를 사용하면 됩니다.

    jobs:
      node-build:
        runs-on: ubuntu-latest
        strategy:
          matrix:
            # 다양한 버전의 Node.js를 이용하여 작업을 여러번 실행
            node: [6, 8, 10]
        steps:
          - uses: actions/setup-node@v1
            with:
              node-version: ${{ matrix.node }}

    캐시 사용하기

    GIthub의 runner는 각 작업에서 새로운 환경으로 실행되므로 작업들이 종속성을 재사용하는 경우 파일들을 캐싱하여 성능을 높일 수 있습니다. 캐시를 생성하면 해당 저장소의 모든 workflow에서 사용할 수 있습니다.

    jobs:
      example-job:
        steps:
          - name: Cache node modules
            uses: actions/cache@v2
            env:
              cache-name: cache-node-modules
            with:
              # `~/.npm` 디렉토리를 캐시해 성능을 높임
              path: ~/.npm
              key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
              restore-keys: |
                ${{ runner.os }}-build-${{ env.cache-name }}-

    Artifact 저장하기

    artifact를 사용하면 job끼리 데이터를 공유하거나 workflow가 끝나고 데이터를 저장할 수 있습니다. workflow에서 생성된 파일을 upload하고, 다른 job에서 사용할 경우 업로드된 파일을 download해서 사용하는 방식입니다.

    job_1에서 math-homework.txt 파일을 생성하고 업로드합니다. 다음 job_2는 job_1에서 업로드한 파일을 다운로드하고 연산한 후, 다시 업로드합니다. job_3은 job_2에서 업로드한 파일을 다운받아 출력하고 끝나는 예시입니다.

    name: Share data between jobs
    
      on: [push]
    
      jobs:
        job_1:
          name: Add 3 and 7
          runs-on: ubuntu-latest
          steps:
            - shell: bash
              run: |
                expr 3 + 7 > math-homework.txt
            - name: Upload math result for job 1
              uses: actions/upload-artifact@v1
              with:
                name: homework
                path: math-homework.txt
    
        job_2:
          name: Multiply by 9
          needs: job_1
          runs-on: windows-latest
          steps:
            - name: Download math result for job 1
              uses: actions/download-artifact@v1
              with:
                name: homework
            - shell: bash
              run: |
                value=`cat homework/math-homework.txt`
                expr $value \* 9 > homework/math-homework.txt
            - name: Upload math result for job 2
              uses: actions/upload-artifact@v1
              with:
                name: homework
                path: homework/math-homework.txt
    
        job_3:
          name: Display results
          needs: job_2
          runs-on: macOS-latest
          steps:
            - name: Download math result for job 2
              uses: actions/download-artifact@v1
              with:
                name: homework
            - name: Print the final result
              shell: bash
              run: |
                value=`cat homework/math-homework.txt`
                echo The result is $value

    레퍼런스

    github action 공식문서

    https://zzsza.github.io/development/2020/06/06/github-action/

    https://meetup.toast.com/posts/286

    댓글