SpringBoot + Gradle 프로젝트의 CI를 GitHub Actions + Docker로 돌립니다 (개)

소개



Spring Boot + Gradle 프로젝트의 CI를 GitHub Actions + Docker로 돌리는 것을 요 전날에서 시도하고 있습니다.
여기 의 문서의 방식에서는, 그 때마다 이미지를 빌드해 버리므로, 비효율하다고 하는 지적을 받았다.

그래서 요전날의 기사와는 다른 방법을 시도했다.

아래 절차.
  • 공용 사용자 정의 Docker 이미지 만들기
  • workflow.yml 수정
  • 커밋 푸시

  • 공개 커스텀 Docker 이미지 만들기



    요전날의 기사와 같이 amazoncorretto:11.0.7 라고 하는 Docker 이미지를 사용한다.
    다만, 이 이미지는 꽤 최소한으로 만들고 있어 디폴트에서는 tar 이나 gzip 커멘드를 사용할 수 없다.
    이대로는 리포지토리의 체크 아웃 등을 할 수 없기 때문에 이들을 설치한 이미지를 준비할 필요가 있다.

    우선은 amazoncorretto:11.0.7 를 베이스로 자전의 이미지를 작성한다.
    DockerHub의 공용 리포지토리로 푸시한다고 가정합니다.

    먼저 아래와 같은 Dockerfile을 준비한다.targzip 를 설치하는 것만 큼 간단합니다.

    Dockerfile
    FROM amazoncorretto:11.0.7
    RUN yum install -y tar gzip
    

    이 Dockerfile을 사용하여 이미지를 빌드합니다.
    docker build .
    

    DockerHub에 리포지토리를 만듭니다.



    DockerHub에 로그인합니다.
    패스워드에는 DockerHub상에서 작성한 토큰을 입력한다.
    docker login
    

    방금 빌드한 이미지에 이름과 태그를 붙인다.
    docker tag {ImageID} shavada/mycorretto:11.0.7
    

    리포지토리에 이미지를 푸시합니다.
    docker push shavada/mycorretto:11.0.7
    

    이제 DockerHub에서 이미지를 풀 수 있습니다.

    workflow.yml 수정



    workflow.yml을 다시 작성합니다.

    ./.github/workflows/workflow.yml
    name: SpringBoot CI with Gradle
    
    on:
      push:
        branches: [ master ]
    
    jobs:
      test-build:
        runs-on: ubuntu-latest
        container:
          image: 'shavada/mycorretto:11.0.7'
        steps:
          - name: Checkout
            uses: actions/checkout@v2
          - name: Add exec Permission
            run: chmod +x gradlew
          - name: Build with Gradle
            run: ./gradlew build
          - name: Archive production artifacts
            uses: actions/upload-artifact@v2
            with:
              name: demo.zip
              path: build/libs/demo-0.0.1-SNAPSHOT.jar
          - name: Archive test reports
            uses: actions/upload-artifact@v2
            with:
              name: test-reports.zip
              path: build/reports/tests/test
    

    아래 URL의 문서에도 쓰여진 대로, 작업의 최초로 container 를 지정할 수 있다.

    이렇게하면 작업의 모든 단계에서 동일한 컨테이너가 사용됩니다.
    또, 앞의 기사와 같이 일부러 Dockerfile을 사용해 그때마다 이미지를 빌드하는 일 없이, 이미지를 풀어 오는 것만으로 끝난다.

    푸시



    수정 커밋을 푸시하면 워크플로가 성공합니다.
    작업의 처음에 컨테이너를 작성해, 그 안에서 처리를 행한 후, 마지막에 컨테이너를 정리하고 있는 것을 알 수 있다.

    좋은 웹페이지 즐겨찾기