Github Actions 훑어보기

Github Actions 이란?

Github Actions 는 Github Repository 에 Actions 탭에 있는 기능이다.

Github References 에 나와있는 Github Actions 소개는 다음과 같다.

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

• Github 안에서 CI/CD 를 지원해줄 수 있고 Code Review, Branch Managament, Issue triaging 등을 원하는 방식으로 자동화 처리하는게 가능하다.
  • Github 에서 여러가지 이벤트가 발생하는데 (push, pull_request, pull_request_review 등) 이런 이벤트가 발생할 때마다 자동화 스크립트인 workflow 를 실행하도록 하는 것.

---

Github Actions 왜 쓸까?

• 시작하기 쉽다. Github 만 있으면 되므로.
• 저렴한 편이다. Public Repository 이거나 Self-Hosted Runner 인 경우 무료이다.
• 여러가지 플러그인을 지원한다. 깃허브 마켓플레이스 에서 다양한 기업이 만든 플러그인을 볼 수 있다.
• GitOps 모델을 지원한다. (시작을 Github 로부터..)
• Matrix builds 가 가능하다.
  • 다양한 환경에서 빌드 테스트가 가능하다.
  • 이런식으로 다양한 OS 와 런타임 환경에서 테스트를 해볼 수 있다.
• 어플리케이션 언어 상관없이 지원한다.
  • Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET 등 많은 언어를 지원한다.
• Troubleshooting 이 쉽다.
  • 빌드와 테스트를 하는 CI 스크립트를 만들었고 그게 실패했다면 이유를 바로 알 수 있다.

• Github Action 의 Status Badge 를 README 에 넣어서 CI 를 통과했는지 시각적으로 알려줄 수 있다.
  

필수 개념

• Github Repository 안에서 .github/workflows 디렉토리 안에서 yaml 파일을 작성하면 된다.
• 다음 예시는 가장 기본적인 Gradle 을 이용한 Java CI 파일이다.

# This workflow will build a Java project with Gradle
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: [ self-hosted ]

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build

• Workflow > Job > Step > Action 으로 구성된다. 그리고 이 Workflow 를 실행시켜줄 조건을 나타내는 Event 가 있다.
• name: workflow 파일 이름
• on: workflow 가 동작하는 조건
  • push, pull-request 말고도 schedule 이라고 해서 정해진 시간에 돌아가도록 할 수도 있다.
  • 이외에 다양한 이벤트를 알고 싶다면 Events that trigger workflows 참조하면 됩니다.
• jobs: workflow 안에서 수행하는 행동을 나타내는 것.
  • 하나의 Job 은 여러 Step 들로 구성되어 있다.
  • 하나의 Workflow 안에서 Job 은 여러 개를 둘 수 있다.
  • workflow 에서 Job 끼리의 환경은 분리되어 있고 서로 병렬적으로 실행한다.
    • 즉 테스트와 빌드를 분리해서 가져가는 경우 테스트 Job 은 빌드 Job 에 있는 빌드 아티팩트를 참조하지 못할 수 있다.
    • Soultion: 빌드 Job 이 끝나면 테스트 Job 을 실행하도록 순서를 정하고, 빌드 Job 의 결과물인 빌드 아티팩트를 특정한 경로에 업로드 하고 테스트 job 은 실행할 때 빌드 아티팩트를 다운로드 한 후 실행하면 된다.
    • 이와 비슷하게 workflow_run 을 통해 Workflow 끼리도 다른 Workflow 실행 완료나 성공에 따라서 자신의 실행을 결정 할 수 있다.
  • runs-on: 가상머신이 돌아갈 환경을 말한다.
    • 빌드 매트릭스를 이용하면 여러 타겟으로 (OS, Node 등) 에서 Job 을 돌릴 수 있다.
• runners: Job 을 실행을 위해 Github 이 제공해주는 서버.
  • Github 의 runner 는 당연하겠지만 job 을 실행하는 환경을 깔끔하게 해서 실행한다. node_modules 와 같은 의존성들이 업데이트 되지않고 재사용하는 경우가 많다면 Caching 을 이용할 수도 있다.
• steps: Job 을 수행하기 위한 과정을 의미한다.
  • uses: 수행할 액션들을 말한다. GitHub Marketplace page 에서 오픈소스로 공개되어 있다.
    • users: actions/checkout@v2 는 가상머신으로 코드를 복사하는 액션을 말한다.
  • run: 은 실행할 명령을 말한다.

---

실제로 사용하는 방법들

기본적으로 사용하는 방법

• Continuous Integration
• Continuous Deployment

브런치 정책 설정과 같이 사용하기

• Github Actions 와 Branch Protection Rule 을 같이 사용해서 브런치 관리를 도와줄 수 있다.
  

• 추천하는 Branch Protection Rule 은 다음과 같음.
  • 브런치에 Merge 하기 전에 PR 을 항상 날려야 하고 최소한의 코드 리뷰가 필요함.
  • Merge 하기 전에 Status Check 를 통과해야 함. (e.g Build 와 Test 같은 CI 자동화된 스크립트)
  • 모든 브런치는 최신으로 유지되어야 머지할 수 있음.
  • 관리자도 이 위의 모든 정책을 따라야 함.

Issue 와 PR 을 관리하기

• Issue 와 Pull Request 관리를 위한 라벨링을 수동으로 하지 않아도 된다. Github Actions 을 통해 자동화 할 수 있다.
• Example
  • 코드 리뷰 Approve 를 받으면 자동으로 PR 에 라벨링을 달아줘서 머지가 가능하다는 정보를 준다던지.
  • 반대로 아직 Merge 가 가능하지 않다면 라벨링을 통해서 시각적으로 정보를 줄 수도 있다.
  • Pull Request 가 어느 Branch 로 머지되는 요청인지도 라벨링을 통해 정보를 줄 수 있다.

Publish Package to NPM on Release

• open source package 를 관리하고 있다면 새로운 버전 출시를 자동화 하는 것도 가능하다.

Scheduled Background Jobs

• cron 을 이용해서 정기적으로 workflow 를 실행하도록 할 수 있다.
• https://crontab.guru/ 이 사이트에서 cron expression 을 몰라도 만들 수 있음

Send Email or Chat Messages

• slack 과 discord, email 에 메시지를 전송하도록 할 수도 있다.
• Review 가 달리거나 Pull Request 가 만들어지면 자동으로 알림이 가도록 할 수 있을듯.
• 아래는 Slack 에 보내는 예시

name: Slack Issues

on:
  issues:
    types: [opened]

jobs:
  post_slack_message:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: rtCamp/action-slack-notify@v2.0.0
    env:
        SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
        SLACK_USERNAME: CyberJeff 
        SLACK_CHANNEL: gh-issues

---

About billing for GitHub Actions

• Public Repository 의 경우 모두 무료.
• self-hosted runners 의 경우도 모두 무료.
• Private Repository 의 사용자의 경우 자신이 사용하고 있는 제품을 넘어서 사용하는 경우 돈을 내야한다.
• 자세한 정보는 여기 참고 https://docs.github.com/en/billing/managing-billing-for-your-github-account/about-billing-for-github-accounts

---

그냥 써보는 Github 의 소소한 팁

• Github 에서 파일 수정을 하고 싶을 때 . 을 누르면 브라우저에서 VS code 가 열린다. (PRO 계정에서만 됨)
• 레파지토리에서 t 를 누르면 파일 검색이 가능하다.
• chrome 확장 플러그인인 octotree 설치하면 Github 에서 파일을 찾아볼 때 편리하다.
  • 옆에서 사이드 탭으로 이전의 히스토리 관리를 도와줌.
• Github 파일 경로에 -history.netlify 를 붙이면 그 파일이 수정된 히스토리를 볼 수 있다. https://github.com/derrickstolee/bundles/blob/main/README.md 를 이렇게 변경하면 된다.
  https://github-history.netlify.com/derrickstolee/bundles/blob/main/README.md

더 알고 싶다면

• Github Actions Reference 를 읽어보자.
  • https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions
• Github Learning lab 에서 실습도 가능하다.
  • https://lab.github.com/

참고문서

• https://docs.github.com/en
• https://www.youtube.com/watch?v=kS3wD-QhYUs&t=587s
• https://fireship.io/lessons/five-useful-github-actions-examples/