ㅇㅇㅈ Blog

프론트엔드 수행중

0%

github actions secrets로 env파일 생성

github actions secrets로 env파일 생성

vite로 구성한 react앱을 github actions로 빌드하고 aws에 배포하는 과정에서
unauthorized 에러가 계속 뜨길래 빌드된 js 파일을 찾아봤더니
env가 포함되지 않아 apikey를 찾지 못하는 에러가 발생하였다.

github secrets에 apikey를 저장해놓고 actions 과정에 env파일을 생성하고,
secrets에 저장해 둔 key를 삽입해 줄 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
name: deploy # 해당 workflow의 이름
on: # 언제 이 action 이 실행 되는지
push: # push를 했을때
branches:
- main # main 브랜치에

jobs: # action
deploy:
runs-on: ubuntu-latest # action이 실행되는 환경?
steps: # step 안에는 shell script를 작성할수도 있고 다른사람이 만들어 놓은 action을 사용 할 수도 있다
- uses: actions/checkout@v3
# GitHub Actions는 해당 프로젝트를 리눅스 환경에 checkout하고 나서 실행

- run: rm -rf node_modules && yarn install --frozen-lockfile
# 노드 모듈을 지우고 나서 새로 설치하라는 터미널 명령
# npm install로 작성해도 된다.

- name: Generate Environment Variables File for Production
run: |
echo "VITE_API_KEY=$VITE_API_KEY" >> .env.production
env:
VITE_API_KEY: ${{ secrets.VITE_API_KEY }}

- run: yarn build
# build

- name: deploy to s3 bucket
uses: jakejarvis/s3-sync-action@master # 다른 사람이 만들어 놓은 action을 가져와서 사용 할 수도 있다.
with:
args: --delete
# github에 환경 변수를 저장해 놓고 사용 할 수 있다.
# aws를 이용해서 배포했으니 aws에 접근할 수 있는 키가 필요하다.
env:
AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: "ap-northeast-2"
SOURCE_DIR: "dist"

gpt에 물어보니

run 키워드는 쉘 명령을 지정합니다. 이 경우, echo 명령을 사용하여 VITE_API_KEY 환경 변수와 해당 값을 .env.production 파일에 추가합니다. $ 구문을 사용하여 VITE_API_KEY 환경 변수에 값이 할당되도록 합니다. 이 값은 GitHub 저장소의 비밀로 지정된 VITE_API_KEY 환경 변수에서 가져오게 됩니다.

처음에는 vite config에 설정을 안해서 그런줄 알고 참 많은 삽질을 했다.
gpt에 물어봐도 config만 설정하라고 계속 알려주길래….
이상한 점은 로컬에서 빌드한 파일에는 apikey가 제대로 들어가 있는데,
actions를 이용해서 빌드한 파일에는 안들어 있다는 점이었다.
그런 과정중에 env파일이 빌드과정에 포함이 안되는걸 알게 되었고,
검색으로 action으로 env파일을 생성하고 key를 삽입해주는걸 찾게 되었고 마침내 성공.

번외 다른 에러

이번엔 firebase에 github actions를 이용해 배포하는 과정에서 생긴 오류.

이번엔 build 과정에서 생긴 에러다.
파일 경로가 잘못되었다고 뜨는데 경로에 문제는 없었다.
이번에도 gpt에 물어봤는데 설정파일을 수정하라고 하는데
그게 문제였으면 로컬에서도 안돌아가야 되는게 맞는거 아닌가!?

일단 문제라고 뜨는 해당 파일을 주석처리하고 해봤는데
이번엔 다른 파일의 경로가 잘못 되었다고 뜬다..

수많은 삽질..

github에 올라간 파일에 문제가있는거니 꼼꼼히 좀 살펴봤는데..
왠걸 github에는 폴더가 대문자로 되어있었다.
분명 중간에 폴더를 대문자에서 소문자로 바꾼거 같긴한데 이게 문제였다.

하긴 배포할때도 로컬 cli에서 바로 배포를 했었으니 그동안 이게 문제인지 인식을 못했었다.

github은 왜 대소문자를 구분 못하는가..

git config에 설정을 추가 해준다

1
git config core.ignorecase false

참고
https://git-scm.com/docs/git-config/2.14.6#Documentation/git-config.txt-coreignoreCase
찾아보니 위 설정이 true일 경우 파일시스템에서 git이 더 잘 작동하도록 하기 위한 것이라고 한다.

예를 들어 디렉토리 목록에서 Git이 “Makefile”을 예상할 때 “makefile”을 찾으면 Git은 실제로 동일한 파일이라고 가정하고 계속해서 “Makefile”로 기억합니다.

다음 git 명령어를 통해 이름을 변경 해 줄 수 있다.

1
git mv api Api

헌데 이 명령어로 이름을 변경할려고 하니

1
fatal: renaming 'client/src/api' failed: Invalid argument

이런 에러가 뜬다.. 역시 찾아보니 같은 문제로 질문이 있었는데 답은

참고
https://clay-atlas.com/us/blog/2021/10/03/git-en-rename-folder-fatal-renaming-failed/

1
2
git mv api temp
git mv temp Api

두 번 하라는 것 -….

근데 mv 명령어 말고 그냥 원격저장소에 올라간 폴더를 지워버리고 아예 새로 올리는 방법도 있다.

1
2
3
git rm -r --cached <폴더 이름>
git commit -m '원격저장소 폴더 삭제'
git push origin <branch>