예전에 기술블로그에 글을 올릴 때마다 깃허브에 기록이 되면 좋겠어서 Github Action 찍먹을 한 적이 있다. 이번에는 졸업작품 개발에 들어가기 전 CI/CD 파이프라인을 구축하기 위해 건드렸는데 정말... 차원이 달랐다..
일단 PTSD를 갖고 있는 MySQL 권한 문제부터 해서 contextLoads() FAILED 문제까지 겹치니 정신이 없었다.. 이렇게 오래 걸릴 줄 몰랐는데 데 자꾸 새로운 에러가 나오니 더 불안했던 것 같다.. 결론부터 말하면 CI/CD 구축은 했다. 하지만 아직 AWS 환경은 연결하지 못했다.. 그래서 이번 글에서는 Github Action CI/CD를 구축하면서 마주칠 수 있는 삽질들을 정리하고자 한다. 다른 분들께 꼭 도움이 되길...
처음에 작성한 yml 코드이다. (.github/workflows/deploy.yml)
name: how-about-trip-webservice
on:
push:
branches:
- master
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Set up JDK 17
uses: actions/setup-java@v1
with:
java-version: 17
- name: Grant execute permission for gradlew
run: chmod +x ./gradlew
shell: bash
- name: Build with Gradle
run: ./gradlew clean build
shell: bash처음 yml을 작성할 때 어떤 것들을 추가해야 될지 몰라서 구글링을 통해 작성했다..
첫 번째 에러: gradlew 위치
당연히 빌드에 실패할 거라고 예상했기 때문에 충격은 크지 않았다. 이때 발생한 문제는 yml 파일의 위치였다.
우리는 교수님께서 만들어주신 하나의 레포에서 개발해야 했기 때문에, 안드로이드와 백엔드가 폴더로 구분되어 있었다.
즉, 이렇게 구분되어 있었다. 지금은 .github 디렉터리가 밖에 나와있지만, 위에서 에러가 발생했을 때는 backend 폴더 안에 들어가 있었다. 허허...ㅠ 아무튼 밖으로 깃허브 폴더를 꺼내준 뒤 다시 빌드를 했다.
그러고 바로 마주한 에러이다. 이번에는 gradlew 파일을 찾지 못하는 문제이다. 당연하다....... gradle 파일은 backend 폴더 안에 있다.. 문제를 해결한답시고 .github 폴더를 backend 폴더 밖으로 빼줬으니 gradle을 못 찾는 게 당연하다.
이 문제를 해결하기 위해서는 두 가지 방법 중 선택을 해야 했다.
1. ./gradlew를 backend/gradlew로 바꾸기
2. working-directory: ./backend 속성을 추가하기
나는 두 번째 방법을 선택해서 문제를 해결했다. 나중에 안드로이드 yml 설정할 때 코드를 재사용하기 위함이다.
두 번째 에러: @Builder.Default 누락
이번에는 무슨 문제인지 정확히 알 수 있었다. @Builder 어노테이션을 사용할 때 초기화할 멤버 변수가 있으면 @Builder.Default 어노테이션을 추가하거나 final 필드를 사용하라는 내용이었다. 우리가 activated 변수를 추가한 이유는 Hard Delete 대신 Soft Delete를 사용하고자 했기 때문에 true로 초기화를 시켜둔 상태였다. 에러 메시지로 알려준 변수들에 @Builder.Default 어노테이션을 붙여서 해결할 수 있었다.
하지만 이후에 나를 가장 힘들게 한 에러를 마주했다.
세 번째 에러: contextLoads() FAILED
contextLoads() FALIED 문제이다. 이 문제는 구글에 검색해 보니 다른 분들도 많이 겪으신 것 같았다. 제일 많이 나온 내용은 데이터베이스 문제였다. 그리고 그제서야 알게 된 것이 있다. 난 여태까지(ㅋㅋ) 데이터베이스도 키지 않은 상태로 빌드를 하고 있었다..
터미널에 입력한 명령어들은 아래와 같다.
brew services start mysql
mysql -u root -pMySQL을 루트 권한으로 실행시켜 두고
- name: Set up MySQL
uses: samin/mysql-action@v1
with:
character set server: 'utf8'
mysql database: 'trip'
mysql user: 'kjy'
mysql password: ${{ secrets.MYSQL_PASSWORD }}해당 속성을 deploy.yml에 추가한 뒤 빌드했다. 비밀번호는 Github Secrets에 추가해 두었다.
똑같은 문제가 발생했다... 이러고 대충 yml만 여러 번 수정한 것 같다. 인텔리제이 환경 변수 설정이나 괜한 MySQL 문법이나.. 등
근데 내가 놓치고 있는 게 있었다......... 말하기 부끄럽지만 로컬 서버를 빌드하지 않았다. 로컬 서버가 잘 돌아가는지도 모르면서 계속 액션만 빌드하고 있었다...
심지어 로컬에서 빌드한다는 것도 선배의 말을 듣고 깨달았다... 정신 차리고 바로 로컬에서 빌드했다.
java.sql.SQLException: Access denied for user 'kjy'@'localhost' (using password: YES)
이 에러가 떴다. MySQL 권한이 없는 문제인 것은 바로 알았다.. 웹서비스 프로그래밍 수업을 들을 때 나를 지독하게 괴롭혔던 문제이기 때문이다. 정신 차리고 이 문제를 해결하고자 했다.
CREATE DATABASE trip;
CREATE USER '유저네임'@'localhost' IDENTIFIED BY '비밀번호';
GRANT ALL PRIVILEGES ON trip.* TO 'kjy'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;해결 방법은 위 명령어이다. 근데 나만 그런 건지 모르겠는데 저렇게 입력해 줘도 권한이 없다는 에러가 계속 뜬다.
ERROR 1146 (42S02): Table 'trip.user' doesn't exist
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
ERROR 1396 (HY000): Operation CREATE USER failed for 'kjy'@'localhost'이 에러들이 계속 떴다..ㅠ
그래서
- 돌아가고 있는 도커 끄기
- 데이터베이스 삭제하고 다시 생성
- SQL 명령문 다시 입력
이걸 계속 반복해 줬다. 왜냐하면 저 네 줄 명령어 말고는 권한을 줄 수 있는 방법이 없었기 때문에 그냥 될 때까지 했다. 그러니까 어느 순간 로컬에서 빌드가 됐다.(진짜 지우고 처음부터 다시 하고, 지우고 처음부터 다시 하고를 반복하기만 했다)
하지만 로컬에서 빌드가 되었다고 해서 Github Action 빌드가 성공한다는 보장이 없었다.
역시 이 에러는 계속 떴다. 더더더 구글링을 해서 안 들어가 본 블로그가 없을 정도로 찾다 보니 두 가지 방법을 찾았다.
💡 가장 효과적이었던 contextLoads() FALIED 문제 해결 방안
1. application.yml에 generate-ddl: true 속성 추가
2. ApplicationTests 클래스에 @SpringBootTest(classes=ApplicationTests.class) 속성 추가
이 두 가지 방법을 설정한 뒤 빌드하니까 됐다.. 빌드가 됐다..!!!
내가 마주한 문제(contextLoads() FAILED)는 CI/CD를 구축하면서 가장 자주 발생하는 문제인 것 같았다. 사실상 삽질은 없었고 그냥 내가 무지해서 지식을 쌓아야 했던 것이기 때문에 좋은 경험이었다.
자 이제 Github Action과 AWS 환경만 연결하면 된다.. 🥹
'Dev > Github' 카테고리의 다른 글
| [Github] Pork Repository가 수정됐을 때 업데이트하기 (0) | 2024.01.07 |
|---|
