複数リポジトリのGitHub Actionsの様子を一覧表示できる「Gitaction Board」を使ってみた
はじめに
今週はとてもインパクトのある事件があったのですが、GitHub ActionsのランナーのデフォルトNode.jsバージョンがnode16からnode20に変更されました。
これはGitHub Actionsが使うプログラムの一部、特に分かりやすいのが「actions/checkout@v3」のように敢えて古いバージョンを指定して動作させている環境で影響があり、実行時に以下のようなエラーが発生します。
～: version `GLIBC_2.27' not found (required by ～/node20/bin/node)
～: version `GLIBC_2.28' not found (required by ～/node20/bin/node)
この症状は多くの人から報告され、actions/checkoutのリポジトリのISSUEにはたくさんのコメントが寄せられています。
エラー発生時の対処方法
このエラーは単純に「actions/checkout@v3」を「actions/checkout@v4」のようにすれば解消されるという訳では無いのがやっかいなところです。
恐らく私の予想では「container」や「image」でnode20に対応していないDockerイメージを指定している場合に発生すると思われ、その場合の対処方法としては以下のようになります。
使用しているDockerイメージをnode20対応のものに差し替える。
環境変数に「ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true」を追加する。
環境変数の設定
「ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION」を設定する方法は色々あるのですが、一番簡単な方法はYAMLに以下を追記するのが良いと思います。
env:
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true参考：
また、私は試していませんが恐らくランナーが動作している環境上で以下のように環境変数を設定すれば、同様の効果があると思われます。
export ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueエラーが発生しているワークフローを探し出す
さて、ここからが本題なのですが、複数のリポジトリでGitHub Actionsを使用していると、どこでエラーが発生しているのか把握しづらいという課題が出てきます。
Organization全体が担当範囲ならまだ良いのですが、Organization内の特定のリポジトリが担当であり、そこの状況を把握したいという時に良いツールが無いか探していたところ、「Gitaction Board」というものを見つけました。
Gitaction Boardについて
このツール、名前の通りGitHub Actionsのジョブの実行状況をダッシュボードで表示してくれるというものになります。
デモサイトが以下になるので、どのような表示になるか参考に見てみてください。
導入手順がこちらに記載されているので、実際に環境構築してみました。
Gitaction Boardのセットアップ
Gitaction BoardはDockerを使って実行することができます。Dockerの実行環境については割愛しますが、イメージをpullして来てrunするだけで起動します。
以下のように順を追って説明します。
Dockerイメージの取得
Dockerコンテナの起動
レートリミットに対する設定
シークレットスキャンとコードスキャンの有効化
Dockerイメージの取得
docker pull ottoopensource/gitactionboard:<docker tag>
具体例：
docker pull ottoopensource/gitactionboard:latest
Dockerコンテナの起動
docker run \
-p <host machine port>:8080 \
-e REPO_OWNER_NAME=<organization/username> \
-e REPO_NAMES=<repo names as comma separated value> \
-it ottoopensource/gitactionboard:<docker tag>
# example:
#docker run \
#--env REPO_OWNER_NAME=webpack \
#--env REPO_NAMES=webpack-cli,webpack-dev-server \
#-p 8080:8080 \
#-it ottoopensource/gitactionboard:latest
具体例（私が管理しているリポジトリでの実行）：
docker run \
-p 8080:8080 \
-e REPO_OWNER_NAME=aegisfleet \
-e REPO_NAMES=github-trending-to-bluesky,qiita-trending-to-bluesky,zenn-trending-to-bluesky,markets-trending-to-bluesky,hugging-face-trending-to-bluesky,genai-trending-to-bluesky,eng-sentences-genai-next \
-it ottoopensource/gitactionboard:latest
これだけで以下のように指定したリポジトリの実行状況を取得することができました。
レートリミットに対する設定
Gitaction BoardはGitHubのREST APIを利用していますが、GitHubのREST APIには実行回数の制限があります。
認証情報を設定せずに実行した場合は「1 時間あたり 60 リクエスト」までとなっており、Gitaction Boardはデフォルトで60秒に1回APIを実行して実行状況を取得することから、すぐの制限に引っかかってしまいます。
解消方法としてはGitHubのトークンを使用してアクセスするのと、APIの実行頻度を減らす、という事に成ります。
それぞれ「GITHUB_ACCESS_TOKEN」と「CACHE_EXPIRES_AFTER」を使って設定します。
具体例：
docker run \
-p 8080:8080 \
-e REPO_OWNER_NAME=aegisfleet \
-e REPO_NAMES=github-trending-to-bluesky,qiita-trending-to-bluesky,zenn-trending-to-bluesky,markets-trending-to-bluesky,hugging-face-trending-to-bluesky,genai-trending-to-bluesky,eng-sentences-genai-next \
-e GITHUB_ACCESS_TOKEN=[ここにトークンを記載] \
-e CACHE_EXPIRES_AFTER=600 \
-it ottoopensource/gitactionboard:latest
シークレットスキャンとコードスキャンの有効化
GitHubにはシークレットのスキャンとコードのスキャン機能があります。これらはデフォルトでは有効化されておらず、有効化する方法は以下を参考にしてください。
Gitaction Boardにはスキャンで検知されたものを表示する機能があり、それぞれ「ENABLE_GITHUB_SECRETS_SCAN_ALERTS_MONITORING」と「ENABLE_GITHUB_CODE_SCAN_ALERTS_MONITORING」で設定します。
具体例：
docker run \
-p 8080:8080 \
-e REPO_OWNER_NAME=aegisfleet \
-e REPO_NAMES=github-trending-to-bluesky,qiita-trending-to-bluesky,zenn-trending-to-bluesky,markets-trending-to-bluesky,hugging-face-trending-to-bluesky,genai-trending-to-bluesky,eng-sentences-genai-next \
-e GITHUB_ACCESS_TOKEN=[ここにトークンを記載] \
-e CACHE_EXPIRES_AFTER=600 \
-e ENABLE_GITHUB_SECRETS_SCAN_ALERTS_MONITORING=true \
-e ENABLE_GITHUB_CODE_SCAN_ALERTS_MONITORING=true \
-it ottoopensource/gitactionboard:latest
すると左側にアイコンが表示されるようになります。私の場合なにも検知されていないのでタコのイラストが表示されますが、検知した場合の表示例を見たければ、先に紹介したデモサイトを見てみてください。
さいごに
GitHub Actionsは残念ながらGitHubの運営方針に影響されるため、放置しているといつの間にか動かなくなるということが起こりえます。
動いていたワークフローが突然動かなくなるという時もあると思いますが、大切なのはそれをいち早く検知して対処することだと思います。
「Gitaction Board」で状況を見れるようにしても、それを確認するプロセスが無ければ意味が無いですし、その辺りも含めて運用を考えないと行けないですね。
ではまた。
いいなと思ったら応援しよう！
