GitHub Actions (beta) を使ってみる

今年の5月にベータ公開されてすぐに申し込んでいました。3ヶ月ぐらい経って僕のアカウントにもローリングでリリースされました。

github.com

元々 HCL*1 ベースでグラフィカルな UI で構築する方式でしたが、僕が使えるようになった時には HCL は非推奨となり 他の多くの CI ツール同様 YAML が標準になりました。

ワークフローがない状態で Actions の画面を開くとプロジェクトの内容に応じたワークフローの雛形がサジェストされます。一度作ってしまうとサジェストされなくなりますが、雛形は以下のリポジトリに集まっているようです。

github.com

例によって Spring Boot のサンプルアプリで試してみます。

github.com

Maven の雛形とDocker image の雛形から作成しました。

f:id:kondoumh:20190822211854p:plain

f:id:kondoumh:20190822223252p:plain

2つのジョブから構成しています。

  • package: Spring Boot アプリのパッケージ(ビルド、テスト、JAR 作成)
  • build-image: Docker イメージビルド

各ジョブは別の Docker インスタンスで実行されます。build-image は needs を使って package の後続ジョブとしています*2

name: Example CI

on: [push]

jobs:
  package:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: ./mvnw package

    - uses: actions/upload-artifact@master
      with:
        name: sb-sample-service.jar
        path: ./target/sb-sample-service.jar

  build-image:

    needs: package
    runs-on: ubuntu-latest
 
    steps:
    - uses: actions/checkout@v1
    - uses: actions/download-artifact@master
      with:
        name: sb-sample-service.jar
        path: ./target

    - name: Build the Docker image
      run: docker build . --file Dockerfile --tag sb-sample-service:$(date +%s)

ビルド成果物の JAR ファイルを ジョブ間で受け渡しできるよう、公式 Action から upload-artifact と download-artifact を使ってみました*3

github.com

github.com

Actions のタブから実行結果を確認できます。

f:id:kondoumh:20190822224105p:plain

ステップ毎に詳細なログを取得できます。upload-artifact によって保存された JAR ファイルをダウンロードすることも可能です。

イメージのビルドもログを見ると成功してタグ付けされたものができているようです。

Run docker build . --file Dockerfile --tag sb-sample-service:$(date +%s)
Sending build context to Docker daemon  33.23MB

Step 1/3 : FROM openjdk:8-jdk-alpine
8-jdk-alpine: Pulling from library/openjdk
e7c96db7181b: Already exists
f910a506b6cb: Pulling fs layer
c2274a1a0e27: Pulling fs layer
f910a506b6cb: Download complete
f910a506b6cb: Pull complete
c2274a1a0e27: Verifying Checksum
c2274a1a0e27: Download complete
c2274a1a0e27: Pull complete
Digest: sha256:94792824df2df33402f201713f932b58cb9de94a0cd524164a0f2283343547b3
Status: Downloaded newer image for openjdk:8-jdk-alpine
 ---> a3562aa0b991
 Step 2/3 : COPY ./target/sb-sample-service.jar sb-sample-service.jar
 ---> f103d9d489ff
Step 3/3 : ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/sb-sample-service.jar"]
 ---> Running in be018d0c3ee0
Removing intermediate container be018d0c3ee0
 ---> 7297e5983b31
Successfully built 7297e5983b31
Successfully tagged sb-sample-service:1566479900

今回はイメージをビルドして終わりでしたが、これまたベータ公開が始まっている Package Registry を使ってビルドしたイメージを Publish することができるようになると思われます*4

github.com

ところで、GitLab もリポジトリ単位で CI / CD を定義できましたが、登録できるパイプライン定義は1つでした。

blog.kondoumh.com

このため、単体テスト、結合テスト、リリースビルドなど様々な目的でパイプラインを作成すると .gitlab-ci.yml が巨大で複雑なものになりがちです。GitHub Action ではワークフローが複数定義可能ですので、様々な目的のワークフローを程よい単位で作成できるのではないでしょうか。

以上、GitHub Actions を簡単に試してみました。リリース版ではさらに完成度が上がっていることを期待しています。

参考記事:

www.kaizenprogrammer.com

*1:HashiCorp configuration language

*2:Docker の Multi-stage build でも同じようなことができますが、ジョブの連鎖として定義することで JAR 作成時のテストとイメージビルドが分離できて、CI の結果が分かりやすくなります。

*3:廃止になったグラフィカルなエディタがあれば、このような Action をオーサリングするのが楽だったのでは・・と思います。

*4:現時点では僕のアカウントではまだ使えません。