fix(ci): dockerbuild ワークフローの起動失敗を解消し PR でも実行可能にする#6784
Conversation
base matrix から外れていた `php: '8.3'` を再加入し、`include` 内の orphan
エントリ `{php: '8.3', tag: '8.3-apache'}` が新規 combination を作って
`runs-on` を空にする問題を解消する。これにより 2026-05-13 以降ずっと
「This run likely failed because of a workflow file issue」で失敗していた
`Testing dockerbuild` ワークフローが起動可能になる。
併せて以下を整理する:
- `on.push` を `workflow_call:` に変更し、`main.yml` から呼び出す
形に統一。`success` ジョブの `needs` に `dockerbuild` を追加し、
PR 時の失敗を `main.yml` の `success` 到達でブロックできるようにする
- PR 時は `Login to GitHub Container Registry` / `Push Docker image`
をスキップ。ビルドと `docker compose up --wait` による起動確認のみ実行
- Codeception 削除 (PR EC-CUBE#6778) で不要になった `Setup PHP` /
`Install ext-redis 6.1+` / `Initialize Composer` ステップを削除
(`.dockerignore` で `vendor/` を除外しているため、ホスト側 composer
install は Docker イメージに反映されず無意味)
Co-Authored-By: Claude <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughdockerbuild.yml ワークフローが再利用可能なワークフローに変更され、main.yml から呼び出されるようになりました。PHP 8.3 サポートが追加され、レジストリログインとイメージプッシュの条件がイベント型に基づいた動作に更新されました。 Changes再利用可能な Docker ビルドワークフロー
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/dockerbuild.yml:
- Around line 46-47: The current conditional if: github.event_name !=
'pull_request' in .github/workflows/dockerbuild.yml is wrong for workflow_call
because github.event_name reflects the caller; replace it with a tighter check
for actual tag/release pushes (for example: if: github.event_name == 'release'
|| startsWith(github.ref, 'refs/tags/')) so the docker/login-action push step
only runs on release/tag events; update the conditional that currently reads if:
github.event_name != 'pull_request' accordingly (or alternatively use ref_type
== 'tag' when available) to ensure Login/Push only executes for tags/releases.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 47a46edb-fe10-4959-844f-cf416621178b
📒 Files selected for processing (2)
.github/workflows/dockerbuild.yml.github/workflows/main.yml
| if: github.event_name != 'pull_request' | ||
| uses: docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In a reusable GitHub Actions workflow triggered by workflow_call, what value does github.event_name have, and what is the recommended way to conditionally skip publish steps for pull_request callers while allowing tag/release publishes?
💡 Result:
In a reusable workflow called via on: workflow_call, github.event_name has the value of the event that triggered the caller workflow (not workflow_call). For example, if the caller was triggered by pull_request_target, then github.event_name inside the called workflow will be pull_request_target—so checks like github.event_name == 'workflow_call' will be false in that called workflow. [1][2][3] Recommended way to conditionally skip “publish” for pull_request callers while allowing tag/release publishes: 1) In the reusable workflow, add an explicit input flag (e.g., should_publish) to represent whether the caller intends to publish. 2) In the caller workflow, set that input based on the caller’s event type (e.g., only set it to true for push tag events / release events, and false for pull_request* events). 3) In the reusable workflow, guard publish jobs/steps with that input, e.g. if: ${{ inputs.should_publish }}. This avoids relying on github.event_name == 'workflow_call', which is not reliable because the called workflow’s github context is associated with the caller workflow’s event. [1][3]
Citations:
- 1: if: ${{ github.event_name != 'workflow_call' }} not working actions/runner#3146
- 2: Cross-repo activation checkout still broken for event-driven relay workflows after #20301 github/gh-aw#20567
- 3: bug: renovate-changeset reusable workflow always skipped for external callers bfra-me/.github#1990
github.event_name の前提がズレています（workflow_call 側でも呼び出し元イベントの値になります）
workflow_callされた側のgithub.event_nameは呼び出し元ワークフローのイベント値のため、pull_requestで呼ばれている場合はif: github.event_name != 'pull_request'により Login/Push は実行されません。- ただし「タグ/リリース時のみ push」が要件なら、現状は
pull_request以外すべてで走り得るためrelease/tag（ref_type == 'tag'等）で条件を絞り込むのが安全です。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/dockerbuild.yml around lines 46 - 47, The current
conditional if: github.event_name != 'pull_request' in
.github/workflows/dockerbuild.yml is wrong for workflow_call because
github.event_name reflects the caller; replace it with a tighter check for
actual tag/release pushes (for example: if: github.event_name == 'release' ||
startsWith(github.ref, 'refs/tags/')) so the docker/login-action push step only
runs on release/tag events; update the conditional that currently reads if:
github.event_name != 'pull_request' accordingly (or alternatively use ref_type
== 'tag' when available) to ensure Login/Push only executes for tags/releases.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.4 #6784 +/- ##
============================================
- Coverage 76.87% 75.10% -1.77%
Complexity 6752 6752
============================================
Files 483 483
Lines 26279 26279
============================================
- Hits 20201 19738 -463
- Misses 6078 6541 +463
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
PHP 8.5.0 から opcache がコアへ静的組み込み (non-optional) となり共有モジュール (.so) を生成しなくなったため、`docker-php-ext-install opcache` が `modules/*` を見つけられず install-modules で失敗していた (8.5 のみ失敗、8.3/8.4 は成功)。 EC-CUBE2 系と同じく、インストール対象を `EXT_INSTALL_ARGS` ビルド引数で外出しし、 ワークフローの matrix で PHP バージョンごとに制御する方式へ変更。8.5 では opcache を install 対象から除外する (組み込み opcache は既定で有効)。 あわせて、存在しないパスを指す不正な `docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql` (ハイフン1個) を削除。 ローカル検証: 8.4 / 8.5 ともにビルド成功し、必要拡張 (zip/gd/mysqli/pdo_mysql/ pgsql/pdo_pgsql/intl/opcache/apcu) のロードと opcache.enable=true を確認済み。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1 participant
概要(Overview・Refs Issue)
Testing dockerbuildワークフロー (.github/workflows/dockerbuild.yml) が 2026-05-13 以降、4.4ブランチで連続失敗していた問題を修正する。失敗 run の例: https://github.com/EC-CUBE/ec-cube/actions/runs/26124921377
GitHub UI には「This run likely failed because of a workflow file issue」と表示され、
gh api /repos/EC-CUBE/ec-cube/actions/runs/<id>/jobsの結果が{"total_count":0,"jobs":[]}となっており、ステップ実行前の workflow ファイル検証段階で失敗していた。合わせて以下を整理する。
main.yml経由で PR でも dockerbuild の失敗を検知できるようにする方針(Policy)
起動失敗の根本原因
dockerbuild.ymlの matrix 定義でinclude内に orphan な{php: '8.3', tag: '8.3-apache'}エントリ が残存していた。base matrix は
php: ['8.4', '8.5'](8.3 が外れている) のため、GitHub Actions の matrix include 仕様 により{php: '8.3', tag: '8.3-apache'}は既存 combination にマージできず新規 combination として作成されるが、この新規 combination にはoperating-systemが含まれずruns-on: \${{ matrix.operating-system }}が空となり workflow 検証エラーで起動失敗していた。直接の起点は 2025-11-25 の commit
42a0cec799(ci: GitHub ActionsでPHP 8.4と8.5のサポートを追加) で base をphp: ['8.4'] → ['8.4', '8.5']に変更しつつ include の 8.3 エントリを残置したこと。2026-05-13 以降は4.4(旧4.3-symfony7) ブランチが現役 CI 対象となり、毎 push で workflow 起動失敗が顕在化していた。修正内容
base matrix に
'8.3'を再加入し、include の 8.3 エントリと整合させる。unit-test.yml/plugin-test.yml/e2e-test.ymlも 8.3 をテスト対象としている点とも揃う。PR 時の失敗検知
dockerbuild.ymlをon.workflow_call:に変更しmain.ymlから呼び出す。successジョブのneedsにdockerbuildを追加し、PR の dockerbuild が失敗すればsuccessに到達しない構成にした。PR では ghcr.io への push は行わず、ビルドと
docker compose up --waitでの EC-CUBE 起動確認までを実施する。不要ステップの削除
#6778 で Codeception が削除されたため、ホスト側で動かしていた以下のステップは不要となり削除する。
Setup PHPInstall ext-redis 6.1+Initialize Composer.dockerignoreでvendor/を除外しているため、ホスト側composer installの結果は Docker イメージに反映されず、これらは Codeception 実行のためだけに存在していた。実装に関する補足(Appendix)
on.releaseは維持。タグ公開時は従来通りdockerbuild.ymlが直接トリガーされ ghcr.io にイメージを push する。main.ymlのdockerbuildジョブにはneeds:を指定しておらず、rector/phpstan/php-cs-fixerと並列で実行される (DX 上、Docker ビルドは早期に結果が出る方が便利なため)。Login to GitHub Container Registry/Push Docker imageはif: github.event_name != 'pull_request'でガード。PR 由来のGITHUB_TOKENがpackages: writeを持たないケースで失敗するのを避けるため。テスト（Test)
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/dockerbuild.yml'))"で OKmain.yml経由のdockerbuildジョブが実際に起動し、各 PHP バージョンで Docker ビルド + EC-CUBE 起動確認まで通ることを確認4.4への push でTesting dockerbuildワークフローが起動し ghcr.io への push まで完了することを確認相談（Discussion）
4.4で 8.3 / 8.4 / 8.5 の 3 並列。CI 時間が気になるようなら PR 時のみ 1 バージョンに絞る等の制限を検討する余地がある。マイナーバージョン互換性保持のための制限事項チェックリスト
レビュワー確認項目
Summary by CodeRabbit