atton.blog: GitHubActions

2020/07/19

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。

前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。

Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。

前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。

これまた前回同様、以降は作業ログ等です。

何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。

ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。

更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。

GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。

Dockerfile が増えた場合も自動で対応する
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。

第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。

構成を変更して良かった点

他の image の README を参考にした結果、 README が整備された

latex-make には使用例が無かったので追記した
shields.io を利用して image のサイズ等のバッジを追加
GitHub/Docker Hub の README を(手動で)統一

Docker Hub に automated build のログが残るようになった

前回は「push したユーザは atton, push 時刻」程度の情報しか無かった

ログイン情報を書くが必要無い

連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた

なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する

構成を変更して良くなかった点

移行作業が手作業だった

対象となる docker image が2つのみだったので、手作業で移行を行なった
仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない

第2条件が若干緩くなった

master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
git の tag をトリガーにして build する、等の設定で修正可能
しかし現状の image の tag は latest しか無いので放置中

2020/06/09

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。

GitHub Actions を作成する際に考慮した条件

Dockerfile が増えた場合も自動で対応する(現時点では2つ)
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。

第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には

ディレクトリ名は任意

ls と [ -d ] で確認

ディレクトリの直下に Dockerfile が存在する

ls と [ -f ] で確認

といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。

第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました。

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。

幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると

$ git diff-tree --no-commit-id --name-only -r ${{ github.sha }}

で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。

更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。

git は存在するか
git の version は何か
git は実行できるか
remote origin は存在するか
commit log は辿る事ができるか
grep の version は何か
...

結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には

git コマンドは実行できる
git show を行なうと、全ファイルが新規作成扱いになっている
origin を fetch しても commit が取得できない

という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。

余談: 第二条件の部分を書いている時に思った事

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

Pull Request を作成して提案する手がある

「ローカルでは動くが、別環境では動かない」

GitHub で動作 Image を提供している可能性がある

「actions/checkout@master を使うと repository の情報が消える(?)」

今は git clone で対応できるが、 branch の指定といったオプションに対応できない

第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては

問題発生時の再現に使用できる
commit 前の Dockerfile も試しに build できる
新しい Image 作成時の build が楽

等があります。なお、この条件は build.sh に与える引数の有無で解決しました。

まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。

結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。

前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」