GitHub Actionsの再利用ワークフローでSecretが空になり、投票欄が消えていた｜secrets: inherit を忘れた話

01 / 本文

結論：再利用ワークフローは、呼び出し元のSecretを自動では受け取らない

uses: で別のワークフローを呼ぶとき、secrets: inherit を書かないと、呼ばれた側の ${{ secrets.XXX }} は空文字になる。エラーにはならない。空のまま処理が進む。

私の場合、ビルド時に埋め込むはずのSupabaseの接続情報が空になり、投票ボタン・口コミ欄・ランキングが存在しないページが配信されていた。

jobs:
  deploy:
    needs: refresh
    uses: ./.github/workflows/deploy.yml
    secrets: inherit          # これが無いとSecretが渡らない
    permissions:
      contents: read
      pages: write
      id-token: write

02 / 本文

何をしていたか

静的サイトを GitHub Pages で配信している。投稿機能だけは Supabase に置いていて、ビルド時に接続情報を埋め込む形にしていた。

ワークフローは2つある。

deploy.yml — ビルドして Pages へ配信する

refresh-data.yml — 週1回、外部APIからデータを取り直し、変化があればcommitして deploy.yml を呼ぶ

この refresh-data.yml から deploy.yml を呼ぶところが問題だった。

03 / 本文

気づきにくい理由

pushでのデプロイでは、まったく正常に動く。

コードを直してpushすれば deploy.yml が直接起動し、Secretはそのまま使える。手元で確認しても問題は出ない。

壊れるのは、データを取り直したときだけだ。週1回の自動実行で静かに壊れ、次に何かをpushすると勝手に直る。再現条件が分かるまで、原因の見当がつかなかった。

見つかったのは、たまたまページを再読み込みして「ランキングと投稿が消えた」と気づいたからだった。

04 / 本文

調べ方：配信されているHTMLを直接見る

ブラウザの表示だけを見ていると、JavaScriptの失敗なのか、そもそもデータが無いのかが分からない。配信されているHTMLを直接取って、埋め込まれるはずの値が入っているか見るのが早い。

私の場合、接続先が空文字になっていることがすぐ分かった。

curl -sSL https://example.com/some-page/ | grep -o 'data-api="[^"]*"'
# → data-api=""   ← 空だった

curl -sSL https://example.com/data/config.json
# → {}          ← 空だった

05 / 本文

同じ経路で、続けて3つ踏んだ

refresh-data.yml → deploy.yml という呼び出しは、落とし穴が集まる場所だった。順に踏んだ。

1. 古いコミットを配信していた。 actions/checkout は既定でワークフロー起動時のSHAを取る。ジョブの中でbotがcommitしても、そのcommitは含まれない。取り直したデータが反映されないまま配信されていた。ref: main を明示して解決した。

2. Secretが渡っていなかった。 本題。secrets: inherit を追加した。

3. commitが止まっていた。 ビルドスクリプトが、commitしないファイル（生成物）も書き換える。そのまま git pull --rebase すると「未コミットの変更がある」と拒まれ、データがpushされない。--autostash を付けて解決した。

3つとも、pushでのデプロイでは起きない。取り直し経由のときだけ起きる。

# 1. 古いSHAを避ける
- uses: actions/checkout@v5
  with:
    ref: main

# 3. 生成物を退避してから取り込む
- run: |
    git add <対象ファイル>
    git diff --cached --quiet && exit 0
    git commit -m "データを取り直す"
    git pull --rebase --autostash origin main
    git push

06 / 本文

教訓：エラーにならない失敗を疑う

3つとも、ワークフローは成功で終わっていた。緑のチェックが付いていた。

Secretが空でもビルドは通る。古いSHAでもビルドは通る。壊れているのは出力の中身だけで、CIはそれを知らない。

配信後に「入っているはずのものが入っているか」を確認する仕組みを入れるべきだった。今回でいえば、デプロイ後にHTMLを取って接続先が空でないかを見る、といった確認だ。それがあれば、週次の実行が壊れた時点で気づけた。

07 / 本文

まとめ

再利用ワークフローには secrets: inherit が要る。書き忘れてもエラーは出ず、空文字で進む。

actions/checkout は既定で起動時のSHAを取る。ジョブ内でcommitするなら ref を明示する。

生成物があるリポジトリで git pull --rebase するなら --autostash を付ける。

そして、CIが成功しても出力が正しいとは限らない。配信後の確認まで含めて初めて、動いていると言える。