Lesstep
GitHub Actions・2026年11月3日に確認

GitHub Actions:「The template is not valid」

実行は始まり、そのあとランナーが評価した式の結果が使えませんでした。ファイルそのものは検証を通っているので、見た目は正しく見えます。行と列は、ワークフローかアクションの action.yml の中の式を指します。どこで止まったかで、どの部分かがわかります:Set up job で2〜3秒なら、ジョブそのもののキー(services:・container: など)。ステップで止まったなら、そのステップの env:・with:・if:・continue-on-error: です。

見え方

The template is not valid. .github/workflows/release.yml (Line: 172, Col: 27): Error reading JToken from JsonReader. Path '', line 0, position 0.
The template is not valid. .github/workflows/build.yml (Line: 185, Col: 21): Unexpected value ''
The template is not valid. System.TimeoutException: hashFiles('code-index.db.gz') couldn't finish within 120 seconds.

1. 「Error reading JToken from JsonReader」:空の文字列への fromJSON

fromJSON('') は失敗するので、設定されなかった出力が式を壊します。いま多いのは release-please です。リリースのプルリクエストを開きも更新もしない実行では pr の出力が空なので、fromJSON(steps.release.outputs.pr).headBranchName がリリースのマージのたびに失敗し(compose-preview-mcp #151)、pulumi-provider-git では10回の実行のうち6回で失敗しました(#54)。

同じステップの if: では防げません。ランナーはステップの env: を if: より先に評価し、その評価が失敗するとステップを失敗にします(StepsRunner.cs)。前のステップが失敗したあとの後ろのステップにもこれをするので、envoyproxy/examples では本当のエラーの上にこのエラーが出ました(#1526)。そのままの文字列を渡してシェルで読むのが、これらのプロジェクトのいくつかがとった直し方です:

- if: steps.release.outputs.pr != ''
  env:
    RELEASE_PR: ${{ steps.release.outputs.pr }}
  run: |
    branch=$(jq -r .headBranchName <<< "$RELEASE_PR")
    echo "branch=$branch" >> "$GITHUB_OUTPUT"

または fromJSON に読めるものを渡します:fromJSON(steps.release.outputs.pr || '{}')。これで防げるのは空の値だけです。自由に書ける workflow_dispatch の入力のような、JSON でない文字列はやはり失敗します(gh-aw #64249)。

2. 「Unexpected value ''」:値が要る場所の空の値

3. hashFiles:「couldn't finish within 120 seconds」

hashFiles() には120秒の決まった上限があり(HashFilesFunction.cs)、** のパターンは、node_modules やジョブがクローンしたりビルドしたりしたものまで、ワークスペース全体をたどります。code-search-index では1つのステップの if: が時間切れになり、そのあとの公開のステップも飛ばされました(#52)。場所がわかっているなら、** を使わずにファイルを名指しします(hashFiles('package-lock.json'))。ファイルがあるかを確かめるだけなら、出力を書くステップはワークスペースをたどりません。code-search-index は hashFiles の条件をこれに置き換えました:

- id: files
  if: always()
  run: |
    if [ -f code-index.db ]; then echo "db=true"; else echo "db=false"; fi >> "$GITHUB_OUTPUT"
- if: steps.files.outputs.db == 'true'
  run: ./publish.sh

4. hashFiles:「An error occurred trying to start process '…/externals/node20/bin/node'」

hashFiles() はランナー自身が持つ Node.js で動きます。ランナー 2.337 まではそれが node20 だったので、node20 の入っていないランナーでは、hashFiles() が毎回失敗します。たいていは actions/cache のキーです。RunsOn の最小のイメージ(runner-images-for-aws #78)と、Nix でパッケージにしたランナー(consortium-autoresearch #49)がそうでした。2.338.0 のリリースノート:「The runner's own Node usage (hashFiles(), ./run.sh --check, and the service wrapper runsvc.sh) now uses Node 24 instead of Node 20」(ランナー自身の Node の利用は Node 20 ではなく Node 24 になった)。ランナーを 2.338.0 以降にすれば直ります。

見分け方

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE(2024.1 以降)のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro(月 US$1.50・30日の無料試用つき)です。

GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに:「Invalid workflow file」 · 「Unable to process file command」 · Docker Hub の取得の上限 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English