test containers를 사용한 ci를 가능하게 하기 위해서, 무엇을 바꿔야 할까?

[nayonsoso]

이 글은 미완성의 글입니다.
'결론' 부분을 완성한 다음에, 위키의 기술 블로그에 추가하려 해요!
제가 저 스스로 내린 결론은 있는데, 여러분들은 어떻게 생각하시는지? 의견을 먼저 듣고 싶어서 디스커션으로 남겨봅니다.
❗️지피티나 다른 도움 없이, 여러분이 정말로 어떻게 생각하시는지를 남겨주세요❗️

---

개요

솔리드 커넥션은 테스트 환경 통합을 위해서, 테스트 실행 시 test containers를 사용하고 있다.
test containers를 사용해서 ci 를 구축하기 위해서는 '별다른 설정이 필요하지 않다'라고 test containers 공식 문서에서는 말하고 있다.

그런데! 필자는 test containers 를 사용한 ci 를 만들기 위해서 시행착오를 많이 겪었다. 😵‍💫
이 글에서는 시행착오를 통해알게된 내용을 공유하고, 최종적인 ci 스크립트를 만들기까지의 의사결정 과정을 공유하려 한다.

---

문제 상황

처음 작성한 ci 스크립트는 아래와 같다.

name: CI with Gradle  
  
on:  
  pull_request:  
    branches: [ "develop", "release", "master" ]  
  
jobs:  
  build:  
    runs-on: ubuntu-latest  
    permissions:  
      contents: read  
      checks: write  
  
    steps:  
      - name: Checkout the code  
        uses: actions/checkout@v4  
        with:  
          token: ${{ secrets.SUBMODULE_ACCESS_TOKEN }}  
          submodules: true  
  
      - name: Set up JDK 17  
        uses: actions/setup-java@v4  
        with:  
          java-version: '17'  
          distribution: 'temurin'  
  
      - name: Setup Gradle  
        uses: gradle/actions/setup-gradle@v4  
  
      - name: Make Gradle wrapper executable  
        run: chmod +x ./gradlew  
  
      - name: Build with Gradle Wrapper  
        run: ./gradlew build  
  
      - name: Publish test results  
        uses: EnricoMi/publish-unit-test-result-action@v2  
        if: always()  
        with:  
          files: "**/build/test-results/**/*.xml"

간단히 요약하자면 이렇다.

• 깃허브에서 제공하는 ubuntu 러너를 사용해서
• 머지의 결과 코드를 대상으로
• JDK 17과 Gradle을 사용해서 빌드 후
• 테스트 결과를 코멘트로 작성

정석적인 ci 과정이라 생각했으나, 계속해서 ConfigDataResourceNotFoundException 예외가 발생했다.

Caused by: org.springframework.boot.context.config.ConfigDataResourceNotFoundException at
ConfigDataResourceNotFoundException.java:97

---

후보 1 - docker 작동 실패

처음에는 테스트 컨테이너 자체가 동작하지 않는 것이라고 판단했다. 🤔
test containers 를 실행하기 위해서는, 해당 머신에 docker가 깔려있어야 한다.
그래서 docker 를 설치하는 action 을 추가하기도 했으나, 결과는 그대로였다.

더 알아본 결과, 내가 사용하는 ubuntu runner에는 docker가 깔려있다.
actions/runner-images/images/ubuntu 의 리드미를 보면,
Installed Software에 docker 가 있음을 확인할 수 있다.
즉, docker가 작동하지 않는 문제는 아니었던 것!

후보 2 - 서브모듈 check out 실패

./gradlew build 명령어가 로컬에서는 정상 작동했다.
하지만 ci 에서는 문제가 있었으니,.. 서브모듈 check out이 실패했을수도 있겠다 생각했다.

결론적으로 이 부분이 문제가 되고 있는게 맞았다!
그런데 원인이 복합적으로 존재했다.

• 서브모듈 체크아웃에 사용되는 토큰은 깃허브 액션의 secret에 저장되어있다.
• 우리 팀의 브랜치 정책에 의해서, 팀 레포에는 develop/release/main 브랜치만 존재한다.
  feature 는 'fork한 레포지토리'에서 새로 생성한다.
  따라서 ci 는 'fork한 레포의 브랜치'로부터 '우리 팀 레포의 develop 브랜치'로의 병합을 대상으로 한다.
• 그런데 깃허브 액션 secret의 정책을 보면,
  fork한 레포로부터 트리거된 워크플로우에는 secret 이 전달되지 않는다고 한다.

---

해결 방법 고민 과정

글의 시작에서 언급했던, 'GitHub action에서 test containers를 사용하기 위해서는 별도의 설정을 하지 않아도 된다'라고 한 test containers의 공식문서는 결국 옳았다..! 😲

문제가 되었던 부분은,

• 우리 팀의 브랜치 전략
• 우리 팀의 환경 변수 관리 방법
• 이들을 모두 지키며 ci 스크립트를 작성하는 것
  이들이 공존할 수 없다는 사실이었다.

문제를 해결하기 위해 고민한 방법들은 다음과 같다.

• ci 용 프로파일을 만들고, 서브모듈(resources/secret)이 아니라 resources/의 하위에 위치시킨다.
  • 아주 직관적인 해결방법
  • 하지만 resources/ 하위에 application.yml 뿐 아니라 application-ci.yml 이 있게 된다는건 뭔가 거슬린다...
  • 그리고 ci를 위한 변수가 test를 위한 변수와 뭐가 다르지..?
    그냥 application-test 로의 분리가 더 나을것 같기도 하다.
• application-test.yml 을 따로 분리하고, test/resources/ 하위에 위치시킨다.
  • 다른 환경들(dev, prod, stage)과는 다른 예외적인 설정 → 한 번 더 생각하게 한다.
• fork한 레포의 feature → 팀 레포의 develop으로 정해뒀던 브랜치 전략을
  팀 레포의 feature → 팀 레포의 develop으로 바꿔서, ci 시에 서브모듈에 체크아웃하게 한다.
  • ci 스크립트나 환경변수 파일을 변경하지 않아도 되므로 간편하다.
  • 팀원들에게 변경의 이유만 잘 전달하면 된다!
  • 하지만 ci 를 위해 시크릿 레포에 체크아웃하는것 자체가 맞는건가? 하는 의문이 든다.

[wibaek]

저는 application-ci.yml이나 application-test.yml을 만들어 resources/ 하위에 위치해야 한다고 생각합니다.

일단 팀 레포지토리 전략을 바꾸어 테스트시에도 secret/에 접근 하는 방식을 사용하면

1. 서브모듈에 대한 의존성이 생깁니다. 특히 서브모듈을 사용하면 형상관리를 할때도 조금씩 딜레이가 생기니(서브모듈 먼저 업데이트하고 본 레포지토리에 서브모듈 업데이트 사항 반영) 비밀로 해야할 dev, prod 환경이면 몰라도 테스트 환경은 그냥 관리해도 좋을 것 같습니다.
2. 설정실수에 따라 prod 환경에 접근하거나, 민감한 데이터가 노출될 가능성이 생길수 있습니다. 원천적으로 테스트를 돌릴때 secret/ 과 분리된 장소에서 돌리게 하는것이 좋을 것 같습니다.

test/resources/ 하위에 위치하는건 다소 어색하다고 느껴집니다. 공개되어 있다는 것을 제외하고 다른 환경 변수와 다르지 않으니 분리할 필요는 없다고 느껴집니다.

[nayonsoso]

저도 yml 파일 분리하는게 좋겠다 생각했어요.
애초에, 테스트의 성패가 소스코드 외부에 있는 서브모듈로 좌우되었던 기존의 구조가 맞았나.. 하는 생각도 들더라고요😅

그리고 위치에 대해서는 /src/test/resources가 표준인듯합니다!

https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

[wibaek]

그렇네요! /src/test/resources 에 넣으면 테스트시에 가장 우선순위로 잡아준다고 하니 여기에 두는게 가장 좋은 방안같네요.

/src/test/resources 경로에 application-test.yml 이 아닌 그냥 application.yml로 두는건 어떻게 생각하시나요? 저는 경로가 나누어졌으니 그냥 application.yml로 두어도 괜찮을 것 같아요.

[Gyuhyeok99]

저도 yml파일 분리하는 게 좋은 거 같아요! 추가로 위백님이 말씀하신 것처럼 /src/test/resources 안에 있어서 테스트 환경이라는 게 경로에서 이미 드러나니까 application-test.yml로 안하고 application.yml로 두는 거 좋은 거 같아요!

[nayonsoso]

좋습니다~ 그럼

• /src/test/resources 하위에
• application.yml 이름으로

만들겠습니다!