Github Actions 배포1 - firebase

euNung·2024년 1월 8일
0

Github Actions

목록 보기
1/1
post-thumbnail

Github Actions

firebase를 사용해서 배포했던 프로젝트에 Github Actions를 사용해서 push를 할 경우 자동으로 배포가 되도록 하고싶었다. 배포를 하기 위해서 'dev 환경 확인 > build 환경 확인 > github push > firebase deploy'를 거치는 과정이 꽤나 번거롭다고 생각했고, github actions를 사용하여 자동 배포를 하면 좋을 것 같다는 생각이 들었기 때문이다.

yml 작성

일단 github actions를 사용하기 위해서는 프로젝트 최상위 경로에 .github/workflows의 디렉터리를 추가해준 후 yml 확장자 파일을 추가해주어야 한다. 초기 설정은 github actions 문서를 보면서 작성했다.

name: Deploy Actions
run-name: Upgrade version & Firebase Deploy
on:
  push:
    branches:
      - master
    paths-ignore:
      - 'back/**'
jobs:
  deploy:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./front
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4
      - name: Setup nodejs
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm ci && npm run build
      - name: firebase deploy
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          entrypoint: ./front
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_TODOLIST_EUNUNG }}"
          projectId: todolist-eunung
          channelId: live

Github Actions workflow 구문

아래 구문들은 위 코드에서 사용한 것을 정리한 것이다.
전체적인 구문들은 github actions에 대한 workflow 구문에서 확인할 수 있다.

  • name & run-name
    name 속성과 run-name 속성은 github 프로젝트의 Actions 탭에서 보여질 이름을 말한다. 아래 사진에서와 같이 확인할 수 있다.

  • on
    어떠한 명령어를 통해 workflow가 수행될 수 있도록 한다.

    • on.push
      push라는 이벤트가 발생하면 workflow가 수행되도록 한다.
    • on.push.branches
      특정한 브랜치에서의 push가 발생한 경우에만 workflow가 수행되도록 한다.
    • path-ignore
      특정 폴더를 제외한 디렉터리에서 on구문의 workflow가 수행되도록 한다.

위 코드에서는 master 브랜치에서 push 되었을 때 workflow가 실행되며, back이라는 폴더 내에서 push된 경우는 무시된다. 해당 프로젝트는 front, back 디렉터리로 프론트와 백을 구분하여 진행하였는데 back 폴더는 현재 자동 배포하고 싶은 프로젝트는 React 프로젝트와 관련이 없으므로 제외시켜주었다.

  • jobs
    수행할 workflow를 작성한다. jobs는 여러개가 될 수 있으며 기본적으로는 병렬로 수행한다.
    jobs.<job_id>.needs 키워드를 사용하여 의존성을 가지도록 할 수 있다.
    • jobs.<job_id>
      해당 작업에 고유한 식별자로 이름을 붙여 구분한다.
      해당 작업은 아래 이미지와 같이 Actions탭에서 해당 workflow history를 선택하면 확인할 수 있다.
    • job.<job_id>.runs-on
      해당 작업이 실행될 운영체제를 선택한다. 기본 예제에 있는 환경을 따랐다.
    • job.<job_id>.defaults.run.working-directory
      해당 작업에서 run 명령어를 수행할 기본 디렉터리를 지정한다.

front 디렉터리에 React 프로젝트가 있으므로 npm ci && npm run build 와 같은 run 명령어들이 수행될 수 있도록 ./front로 지정해주었다.

  • job.<job_id>.steps
    workflow 내부의 job들은 steps의 순서대로 수행된다.
    • job.<job_id>.steps.name
      step의 이름을 지정한다.
    • job.<job_id>.steps.uses
      step에서 사용할 action을 선택한다.
      actions/checkout@v4는 실행환경에서 프로젝트의 저장소에 접근할 수 있도록 한다.
      actions/setup-node@v3는 node 명령어를 수행하기 위해 nodeJs를 설치한다.

firebase 관련 구문

firebase 관련 부분은 firebase 공식 문서를 통해 확인 후 설정하였다.
거의 그대로 옮겨 왔기에 어려운 것은 없었다.
firebase github actions 관련 문서

env 설정

이렇게 작성한 github actions 배포가 통과되고 배포된 사이트를 확인해보았더니 오류가 발생했다. 바로 env 파일 때문이었는데 개발 환경에서 env 설정에서만 확인한 후 배포 환경에 env 파일을 따로 업로드해야 한다는 사실을 잊고 있었다.
안타깝게도 firebase에서 env 설정을 하기 위해서는 functions라는 기능을 사용해야했고 그것은 유료였다.😢
백엔드 쪽에서 pythonanywhere를 통한 결제가 이미 있는 상황이었고 프론트는 vercel에서 환경 변수를 설정할 수 있는 것으로 알고 있었다. 거의 끝마친 상황에서 마무리를 못해서 아쉬웠지만 끝까지 github actions를 통한 자동 배포를 하고 싶었고 추가적인 결제는 하고 싶지 않았기에 배포 환경을 vercel로 변경하기로 하였다. 다음 포스트에서는 vercel에서 github actions 설정을 알아보겠다.

profile
프론트엔드 개발자

0개의 댓글