atton.blog: 6月 2020

私は作成した 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 で解決。

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

参考文献や関連した文献など

私はブログに記事を引用する際、 URL だけ書く事はあまりしません。
何かの文字列に関連付けたり、記事のタイトルに関連付けます。特に後者は参考文献の場合によく行ないます。
これが結構面倒なので、タイトルを取得する Docker Image を作りました、というログです。

環境

OS: macOS Mojave 10.14.6
Docker for Mac: version 19.03.8, build afacb8b

実行例

$ docker run --rm atton/webpage-title 'https://attonblog.blogspot.com/2020/04/upgrade-awscli-with-linked-python38.html'
=> atton.blog: Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する

'、' は curl で取得すると escape されて 、 になる事についても問題無し。

作成した経緯

最初は curl に grep で title タグを取得する、くらいの shellscript を使っていました。

それが次第にタグの attributes を考慮したり、sed を挟んだり、と色々拡張する事に。

最終的に『header に title は無く、JavaScript で後から設定する』サイトに遭遇。これは curl では厳しい。

この際ブラウザを動した方が色々と問題解決できるのでは、という事で chromium を headless で動かす事にしました。
DockerHub の repository は atton/webpage-title で、Dockerfile は GitHub に置いてあります。

記事のタイトルを取得する為だけに大仰なのでは、という感もあります。
ですが、現状タイトルの取得に失敗した事が無いので、個人的には十分満足しています。

atton.blog

2020/06/09

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