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

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

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

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

そもそも GitHub Actions の secrets ってなに？

• 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 による操作だと Actions の secrets は使えない

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

Dependabot secrets の設定に Actions と同じ設定を入れよう

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

その2: action ライブラリのバージョンをメジャーのみで指定する時に注意すべきこと

• 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で助けられたという嬉しいフィードバックがあったので個人ブログの方でも公開してみました。

おまけ: GitHub Actions に移行して便利になった点

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

• トリガーにできるタイミングがかなり増える
  • 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内でコンテナの設定を記述するだけで、ジョブの立ち上げ時にコンテナ起動のステップが走る仕組み
• 複合アクションやワークフローの再利用 を使って見通しの良いワークフロー設計ができる