Skipped CI build and E2E jobs for non-code changes#27311
Conversation
Narrowed the shared paths-filter anchor from .github/** to only CI-relevant paths (workflows, actions, scripts), so changes to renovate config, CODEOWNERS, issue templates, and other non-CI metadata no longer trigger all test suites. Expanded the any-code filter to exclude documentation, IDE config, AI agent config, and other non-code files. Wired the changed_any_code gate into job_build_artifacts, job_build_e2e_public_apps, job_build_e2e_image, and job_e2e_tests which previously ran unconditionally on every PR. These jobs skip cleanly since job_required_tests treats skipped dependencies as passing, and downstream jobs (trigger_cd, publish_ghost) already check for result == success. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
WalkthroughThe CI workflow configuration was modified to apply more granular change detection logic. The workflow now restricts CI-related file changes to specific subdirectories under 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #27311 +/- ##
=======================================
Coverage 73.46% 73.46%
=======================================
Files 1545 1545
Lines 123686 123686
Branches 14961 14962 +1
=======================================
Hits 90870 90870
+ Misses 31819 31797 -22
- Partials 997 1019 +22
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:
|
![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 the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci.yml:
- Line 831: Update the conditional that gates job_build_artifacts so it also
runs for tag pushes/releases; currently it uses the exact condition
"needs.job_setup.outputs.changed_any_code == 'true'". Replace that single-only
check with a compound condition that keeps the existing changed_any_code check
OR allows execution when the workflow ref is a tag (github.ref starts with
"refs/tags/") or when the event indicates a release, ensuring tag pushes will
trigger job_build_artifacts and satisfy downstream requirements like
publish_ghost.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d21fdb2c-0913-4a05-bf5a-24994bee3d63
📒 Files selected for processing (1)
.github/workflows/ci.yml
| job_build_artifacts: | ||
| name: Build & Publish Artifacts | ||
| needs: [job_setup] | ||
| if: needs.job_setup.outputs.changed_any_code == 'true' |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For GitHub Actions pushevents triggered by creating a tag, what values are typically present forgithub.event.commitsandhead_commit, and can changed-file detection resolve to no changes for such events?
💡 Result:
For a GitHub Actions push event whose ref is a newly-created tag (e.g. refs/tags/v1.2.3):
-
github.event.commits: commonly an empty array ([]), because no commits were “pushed” in the sense of being part of thecomparebetweenbeforeandafter—the ref moved/was created, but it typically points at an existing commit. An example tag-push payload showsbeforeas all-zeroes,created: true, andcommits: []. [3] (See also the definition ofcommitsas “pushed commits” in the push payload docs. [1]) -
github.event.head_commit: present and populated with the commit object for the commit the tag points to (i.e., the payload’safterSHA). GitHub explicitly changed tag-creation push payloads to always include a consistenthead_commitfor tag creation. [2] -
Changed-file detection can be “no changes”: yes. If your workflow/action determines changed files from
github.event.commits(or from per-commit file lists), a tag-creation push can legitimately yield zero changed files becausecommitsmay be empty. [3] Also note that in the Actionspushpayload, commit objects don’t includeadded/removed/modifiedfile lists anyway, so file-change detection often has to fall back to Git history/API—and for a tag creation that can still resolve to “no changes” depending on what you compare against. [4]
Sources:
[1] GitHub Docs – push webhook payload fields (commits, head_commit) https://docs.github.com/en/enterprise-cloud@latest/webhooks/webhook-events-and-payloads
[2] GitHub Changelog – consistent head_commit on tag creation (push payload) https://github.blog/changelog/2021-10-01-the-push-webhook-payload-provides-a-consistent-head_commit-on-tag-creation/
[3] Example tag-push context showing commits: [] and populated head_commit https://blog.mikepenz.dev/a/github-actions-context/
[4] GitHub Docs – Actions push event notes (no added/removed/modified in commit objects) https://docs.github.com/en/actions/reference/events-that-trigger-workflows
🏁 Script executed:
# First, let me locate and inspect the workflow file
find . -name "ci.yml" -path "*/.github/workflows/*" -type fRepository: TryGhost/Ghost
Length of output: 84
🏁 Script executed:
# Get an overview of the workflow file structure
wc -l .github/workflows/ci.ymlRepository: TryGhost/Ghost
Length of output: 87
🏁 Script executed:
# Search for job_setup and its outputs
rg -n "job_setup" .github/workflows/ci.yml -A 3 -B 3 | head -100Repository: TryGhost/Ghost
Length of output: 3672
🏁 Script executed:
# Search for changed_any_code definition
rg -n "changed_any_code" .github/workflows/ci.yml -B 5 -A 2Repository: TryGhost/Ghost
Length of output: 2481
🏁 Script executed:
# Search for job_build_artifacts definition and its dependencies
rg -n "job_build_artifacts" .github/workflows/ci.yml -B 2 -A 10Repository: TryGhost/Ghost
Length of output: 6163
🏁 Script executed:
# Look for downstream jobs that depend on job_build_artifacts
rg -n "needs\.job_build_artifacts" .github/workflows/ci.yml -B 2 -A 2Repository: TryGhost/Ghost
Length of output: 2592
🏁 Script executed:
# Search for the "changed" step in job_setup that produces the any-code output
rg -n "id: changed" .github/workflows/ci.yml -A 20 | head -60Repository: TryGhost/Ghost
Length of output: 779
🏁 Script executed:
# Also check if there are any tag-specific handling in job_setup
rg -n "is_tag" .github/workflows/ci.yml -B 3 -A 1 | head -80Repository: TryGhost/Ghost
Length of output: 2964
🏁 Script executed:
# Check the full job_setup to understand its structure
sed -n '37,230p' .github/workflows/ci.ymlRepository: TryGhost/Ghost
Length of output: 7638
Ensure artifact builds run on release tags to prevent blocking downstream tag-release jobs.
job_build_artifacts is currently gated only by changed_any_code. For tag pushes, GitHub Actions provides an empty commits array (since no commits are "pushed"—the tag points to an existing commit), causing the paths-filter action to detect zero changed files and skip the job. This breaks downstream tag-release jobs like publish_ghost that explicitly require job_build_artifacts.result == 'success'.
🔧 Proposed fix
- if: needs.job_setup.outputs.changed_any_code == 'true'
+ if: needs.job_setup.outputs.is_tag == 'true' || needs.job_setup.outputs.changed_any_code == 'true'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml at line 831, Update the conditional that gates
job_build_artifacts so it also runs for tag pushes/releases; currently it uses
the exact condition "needs.job_setup.outputs.changed_any_code == 'true'".
Replace that single-only check with a compound condition that keeps the existing
changed_any_code check OR allows execution when the workflow ref is a tag
(github.ref starts with "refs/tags/") or when the event indicates a release,
ensuring tag pushes will trigger job_build_artifacts and satisfy downstream
requirements like publish_ghost.
|
Closing in favour of the approach in #27297, which will hopefully shake this out better |
1 participant
Summary
What this skips for non-code PRs
The entire Docker build + E2E chain (~90 runner-minutes across 8 shards + 3 build jobs), plus lint and unit tests. For a config-only PR, CI now runs just Setup and the gate job.
What is safe
Test plan