GitHub Actions を触ってて遭遇した細かい詰まりどころ集 (original) (raw)

桐生あんずです。会社のチームのリポジトリの CI/CD を CircleCI から GitHub Actions に移行した際に遭遇した GitHub Actions周りの細かい詰まり所を2点紹介します。

その1: GitHub Actions の CI用に secrets を追加する時は dependabot secrets にも環境変数の設定を入れよう

GitHub のリポジトリの設定で dependabot secrets を設定していなかったことでdependabot が作成する PR の RSpec のワークフローがずっと失敗していしまっていた。

GitHub Actions でのシークレットの使用 - GitHub Docs
- シークレットは、組織、リポジトリ、またはリポジトリ環境内に作成する変数です。作成したシークレットは、GitHub Actionsワークフローで利用できます。 GitHub Actions でシークレットを読み取ることができるのは、シークレットをワークフローに明示的に含める場合のみです。
GitHub Actions のワークフローで CI (例: RSpec ) を動かす時、環境構築時に使うセンシティブな環境変数を GitHub の secrets で設定する運用にしていた
GitHub のリポジトリページの Setting 内にある Secrets and variables の Actions で secrets を作成
- 上記の設定画面内で環境変数を設定し、ワークフロー上で secrets コンテキストで値を取り出せる仕組み
  * 例: ${{ secrets.SENSITIVE_KEY }}
  * https://docs.github.com/ja/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow

dependabot でワークフローを操作する際に secrets の値を呼び出せず空のまま実行されてしまう
人間の手でもう一回ワークフローを実行すると secrets は呼び出せて成功する
- なので「もう一回実行したら成功したしまぁええか」と判断してしまいしばらく原因に気付けていなかった

dependabot の場合は Dependabot secrets の方で環境変数を作成しないと secrets を呼び出せない模様
Secrets and variables の Dependabotの項目で secrets を設定する
上記の設定画面でActions で設定した同様の環境変数を入れておく
この設定をしたら Dependabot によるワークフロー操作の時も secrets を呼び出せる。dependabot が作るPR でも CI が成功するのを確認 🎉
ちなみに 2021年3月までは Actions secrets の方でも呼び出せていたようだ
- GitHub: Dependabot で GitHub Secrets にアクセスさせる | knmts.com

GitHub Actions でライブラリを利用する時、以下のようにメジャーバージョンだけ記述する書き方ができる
- この書き方で指定すると自分達でアップデートする手間なく自動でマイナー、パッチバージョンの更新を取り込むことができる
steps: - uses: actions/checkout@v4
どのライブラリでも必ず使えるわけではない。ライブラリ開発者が自前でタグ or ブランチを用意してくれていたら使える仕組み
- 探し方の例
  * 使うライブラリのタグ一覧を見て、v4といったようなメジャーバージョンのみのタグがあれば使える
  * https://github.com/actions/checkout/tags
  * https://github.com/actions/checkout/releases/tag/v4

dawidd6/action-download-artifact action のマイナーアップデートでAPIレート上限を超えるリクエストを叩く挙動が入った影響でワークフローが一時的に使えなくなってしまった(2024/02)
- https://github.com/dawidd6/action-download-artifact/pull/270#issuecomment-1947414761
  * > @romangg @dawidd6 Hello, it looks like the latest version of this action is exhausting our GitHub rate limit. From a very cursory look it seems like you're getting all workflow runs in the current repo if the immediate workflow run is unable to be found, and then checking the workflow run against the GitHub API for every run in said repo. That's a lot of requests.
upload-artifact action の v4 に破壊的変更が入ってデフォルトで隠しファイルはアップロード対象に含まれなくなった(2024/09)
- https://github.com/actions/upload-artifact/releases/tag/v4.4.0
- Notice: Breaking Changes ⚠️ We will no longer include hidden files and folders by default in the upload-artifact action of this version. This reduces the risk that credentials are accidentally uploaded into artifacts. Customers who need to continue to upload these files can use a new option, include-hidden-files, to continue to do so.

自動で更新が入るのは手間が減るが、想定できない不具合・変更が入ることが実際にある
- 最悪のパターンとしてセキュリティ的に問題のある変更が入った時にすぐ防げないといった例も考えられる
GitHub 公式が提供している信頼できる action に関してはメジャーのみでも良いかなと思いつつ、最近だと upload-artifact@v4 で破壊的変更が入ったみたいなケースもあるので判断が難しい
それ以外の action はパッチバージョンまで指定して利用した方が安全だと考えている
- もしくは使うこと自体を避ける

触っていてわりかし汎用的な詰まりどころだった2点を紹介しました。
この内容はもともと社内の esa で ship it していたものだったのですが、同僚から困った時にこのtipsで助けられたという嬉しいフィードバックがあったので個人ブログの方でも公開してみました。

移行して以下の点が便利になった印象です。

トリガーにできるタイミングがかなり増える
- CircleCI はコミットのpush時(tag push も含まれる)、定期実行、手動実行(Trigger Pipeline)など
- https://circleci.com/docs/ja/triggers-overview
  * GitHub Actions の場合は上記以外に GitHub 上の各アクションにトリガーを設定できる
  * ワークフローをトリガーするイベント - GitHub Docs
  * PR のapprove 時、PRコメント投稿時など
runs-on: で実行環境をシンプルに指定できる
- https://docs.github.com/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on
  * 特にこだわりがなければ runs-on: ubuntu-latest を使う
action の setup ライブラリを使えば数行で主要ライブラリをインストールできるしキャッシュもできる
- https://docs.github.com/ja/actions/automating-builds-and-tests
サービスコンテナを使えば同じネットワーク内のコンテナ構築がシンプルにできて便利
- CircleCI でやっていた wait_for_db jobs で一個ずつコンテナを起動するやり方をしなくていい
- jobs.<job_id>.services内でコンテナの設定を記述するだけで、ジョブの立ち上げ時にコンテナ起動のステップが走る仕組み
複合アクションやワークフローの再利用を使って見通しの良いワークフロー設計ができる