이 글 이후 GitHub Actions가 많이 바뀌었으므로 새로 업데이트된 내용인 GitHub Actions 워크플로우 사용하기를 참고하세요.

지난 GitHub Universe 2018에서 GitHub Actions라는 기능이 발표되었다. 기존에 이미 GitHub과 연동해서 서드파티 서비스를 이용하면서 개발 워크플로우를 자동화하고 있었지만, 대부분의 커스터마이징할 수 있는 워크플로우는 CI가 중심에 있었다. 예를 들어 코딩 관례 검사, 테스트, 빌드 등을 테스트하고 Docker나 팩캐지를 배포하거나 릴리스를 만드는 작업을 CI를 이용해서 했다면 이러한 워크플로우를 직접 다룰 수 있는 기능이 Actions라는 이름으로 GitHub이 직접 지원하기 시작한 것이다.

좋은 서비스들이 많이 있지만 각 서비스가 모든 기능을 지원하는 것은 아니므로 상당 부분 원하는 대로 사용하려면 CI에서 직접 스크립트를 작성해야 했는데 GitHub이 직접 이러한 워크플로우를 제어할 수 있도록 지원하기 시작한 것이다. 실제로 얼마나 편한지는 다양하게 사용해 봐야겠지만 데모에서는 코드를 푸시하면 npm에 패키지를 배포하거나 Docker Hub에 이미지를 배포하거나 AWS, GCP, netlify에 서비스를 배포하는 작업을 GitHub에서 바로 할 수 있다.

아직은 GitHub Actions는 Beta로만 공개된 상태이고 신청을 하고 허가가 나야 사용할 수 있다. 정확히 베타가 얼마나 공개되었는지 알 수 없지만, 현재 베타 기간에는 Private 저장소에만 제공하고 있으므로 간단히 GitHub Actions가 어떻게 동작하는지 살펴보려고 한다.

GitHub Actions are currently available as a limited public beta, which means you should avoid using it for high-value workflows and content during this beta period. Creating workflows that use GitHub Actions is limited to private repositories during the limited public beta.

GitHub Actions

퍼블릭 베타에 초대받고 나니 Private 저장소에서는 "Actions" 탭이 활성화되었다.

Workflow 생성을 누르면 .github/main.workflow를 만들기 위한 GUI 에디터가 나타난다. Actions의 워크플로우는 .workflow 확장자를 가지게 된다.

첫 이벤트는 기본으로는 on push인데 수정을 누르면 create, deployment, fork, gollum, issue_comment 등 GitHub의 다양한 이벤트를 기반으로 워크플로우를 시작할 수 있다.

첫 이벤트의 파란 점을 아래로 연결하면 워크플로우를 연결할 다른 액션을 선택할 수 있다.

현재 지원하는 액션에는 GitHub Action for npm, Filters for GitHub Actions, GitHub Action for Google Cloud, GitHub Action for AWS, Docker Registry, GitHub Action for Zeit, GitHub Action for Heroku 등의 액션이 있다. 아직 기본 제공하는 액션이 다양하지는 않다.

액션을 선택하면 시크릿 환경변수나 환경변수를 지정할 수 있다. GITHUB_TOKEN은 기본으로 지정되고 추가로 원하는 설정을 할 수 있고 대부분의 액션은 Docker 기반이라서 ENTRYPOINT나 CMD를 커스터마이징 할 수 있는 것으로 보이는데 어느 정도 활용할 수 있는지는 좀 더 살펴봐야 알 수 있을 것 같다. 환경변수를 몇 가지 추가해 보았는데 기본적으로 한 워크플로우의 모든 액션에 체크만 하면 추가로 지정하지 않고도 사용할 수 있도록 공유된다.

이렇게 만든 워크플로우는 실제로는 HCL로 작성된 파일로 저장된다. 에디터보다 코드로 작성하는게 편해지려면 약간 시간이 필요할 것 같다.

지금 테스트에서는 on push에 트리거를 걸었으므로 워크플로우 수정사항을 저장하거나 새로운 커밋을 올리면 워크플로우가 시작된다. 워크플로우는 CI처럼 진행 중과 성공/실패의 최종 결과가 표시되어서 예상했던 느낌대로 CI의 많은 부분을 대체할 수 있다고 생각한다.

워크플로우가 성공하면 아래처럼 각 단계의 성공상태가 나타나고 로그도 볼 수 있다.

앞에서 얘기한 대로 CI와 경쟁 구도가 되지 않을까 생각했지만 실행된 로그를 보면 Travis CI와 연동해서 워크플로우가 동작하는 것으로 보이고(예상) 로그를 보면 도커를 기반으로 돌아가는 걸을 알 수 있다. 도커 자체가 독립적으로 실행할 수 있는 환경이기는 하지만 여기서는 테스트로 제공된 것만 그냥 연결해 본 것이고 실제 원하는 워크플로우를 만들려고 할 때 디버그하거나 로그를 확인할 때 얼마나 편할지는 사용해봐야 알 것 같다.

워크플로우는 일렬로만 연결할 수 있는 것은 아니고 병렬로 늘려서 여러 작업을 동시에 수행할 수도 있다.

기존 개발 관련 워크플로우를 CI나 서드파티 서비스로 대부분 소화하고 있었기에 당장 Actions로 어떤 부분을 대체할지 아직 생각나는 부분은 없다. 이미 CI로 작성해 놓은 스크립트를 굳이 바꾸는 것도 귀찮기도 하고... 그래도 GitHub에서 기본으로 제공하는 기능의 편의성이 있으니 활용할 수 있는 부분을 좀 더 고민해 봐야겠다.