ci(web-deploy): only commit blog baseline on push, not on PRs

[bpamiri]

Summary

• Gate the Commit pre-refreshed blog baseline step in visual-regression on github.event_name == 'push' so it stops running on PRs and being rejected by branch protection.
• The step git push origin HEAD:develops the auto-refreshed web/tests/visual-baselines/blog.png. On PR runs that push is rejected with GH013 ("Changes must be made through a pull request"), failing the whole job even when the regression check itself passed.
• The workflow's own block comment at .github/workflows/web-deploy.yml:205-210 already documents the auto-refresh as push-only ("Push events (merges to develop) ALWAYS run the regression … because the post-merge auto-refresh of the blog baseline lives in this job"). Code and comment had drifted; this realigns them.

Trigger pattern

A PR that's behind develop, where develop has merged a web/content/blog/posts/ change since the branch point:

1. detect-scope sees that file as "changed" in the PR diff (the PR branch doesn't have it yet).
2. blog_content_changed=true, so Pre-refresh blog baseline before regression test runs and regenerates the baseline locally.
3. Run visual regression passes (steps.regress.outcome == 'success').
4. Commit pre-refreshed blog baseline fires under the old condition, attempts git push origin HEAD:develop, and is rejected — failing the job.

Observed on #2827.

What's NOT changed

• Pre-refresh blog baseline before regression test (line ~268) stays as-is — it only regenerates a local baseline so the regression check has something current to compare against. It doesn't push, so it doesn't fail on PRs.
• Retry logic (1..5 attempts, fetch+rebase, exit 0 on rebase conflict) is unchanged. The push-time race against parallel merges on develop is still handled the same way.

Test plan

• Confirm CI on this PR shows visual-regression either skipping the commit step (when blog_content_changed=false) or running it conditionally without the push attempt (when blog_content_changed=true).
• On the next push to develop that touches web/content/blog/posts/, confirm the auto-refresh push still fires and succeeds.

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer A

TL;DR: Minimal, correct CI fix. Adds github.event_name == 'push' as the first guard on the "Commit pre-refreshed blog baseline" step so that the git push origin HEAD:develop it contains never fires on PR runs. The change realigns code with the block comment at lines 205-210 that has always documented push-only behavior for the auto-refresh. Verdict: approve.

Correctness

The logic is sound across all three relevant scenarios:

Event	blog_content_changed	regress.outcome	Step fires?
push	true	success	Yes — as intended
push	true	failure	No — correct (don't commit on regression)
pull_request	true	success	No — correct (can't push; branch protection)

The Pre-refresh blog baseline before regression test step (line 269) intentionally has no event_name guard — it regenerates the baseline in-place so the comparison is fair on PRs. Only the subsequent commit+push step needs the guard added here, and that is exactly what this PR does.

The retry loop (lines 308-333) and the rebase-conflict exit-0 path are unchanged and still function correctly for the push path.

Commits

ci(web-deploy): only commit blog baseline on push, not on PRs

Type ci is in the allowlist, scope is optional and unrestricted, subject is sentence-case and well under 100 characters. Commit conforms to commitlint.config.js.

[wheels-bot]

Line1

[wheels-bot]

Wheels Bot -- Reviewer B (round 1)

A's review checks out. The truth table covers the three failure-relevant combinations, the explanation of why the pre-refresh step (line 269) intentionally stays unguarded is accurate, and the commit message assessment is correct. No issues with A's analysis or verdict.

Sycophancy

None detected. The approve verdict is backed by explicit scenario analysis and a reference to the existing block comment at lines 205-210 that already documented push-only intent.

False positives

None detected. Verified against the diff: the single added line is github.event_name == 'push' && as the first condition in a YAML literal-block if: expression. A's truth table correctly represents the resulting gate. The distinction A draws between the local-only pre-refresh step and the commit+push step is accurate.

Missed issues

None detected. This is a CI-only change -- no CFML code touched, so cross-engine concerns do not apply. The condition syntax is valid GitHub Actions expression syntax in a YAML literal block. No security, migration, or DI subsystems are in scope.

Verdict alignment

A's approve is consistent with the findings: a correct, minimal, well-explained guard that realigns code with existing documentation.

Convergence

Aligned. A's analysis is accurate and the approve verdict is appropriate for this change.

[wheels-bot]

Wheels Bot — Reviewer A

TL;DR: This PR adds github.event_name == 'push' && as the first guard on the "Commit pre-refreshed blog baseline" step in the visual-regression job, preventing the git push origin HEAD:develop from firing on PR runs where branch protection would reject it (GH013). The change is minimal, correct, and precisely targeted. The head SHA (20a798560) is a merge-from-develop sync commit; the substantive PR change remains the single line at 9e27f3a47. Verdict: approve.

Correctness

The added guard is the right fix for the described failure mode. The three relevant event × condition combinations all behave correctly after this change:

Event	blog_content_changed	regress.outcome	Step fires?
push	true	success	Yes — push proceeds as intended
push	true	failure	No — existing steps.regress.outcome == 'success' guard prevents it
pull_request	true	success	No — new event_name == 'push' guard blocks it

The Pre-refresh blog baseline before regression test step (line 269) correctly has no event_name guard — it regenerates a local baseline so the comparison is valid on PRs without attempting a push. Only the downstream commit+push step needed the guard, and that is exactly what this PR adds.

The retry loop (lines 308–333), the fetch+rebase path, and the rebase-conflict exit-0 path are all unmodified and continue to work correctly for push events.

Commits

ci(web-deploy): only commit blog baseline on push, not on PRs

Type ci is in the commitlint.config.js allowlist, the subject is sentence-case and well under 100 characters, and the commit body explains the trigger pattern and the workflow comment it aligns with. DCO Signed-off-by trailer is present and matches the author identity.

The head commit (20a798560) is a merge from develop with no changes to this workflow file — it does not affect the review.

[wheels-bot]

Wheels Bot — Reviewer B (round 1)

A's review checks out on the new head SHA. The truth table is accurate against the diff, the distinction between the local-only pre-refresh step and the commit+push step is correct, and the commit metadata assessment is right. No issues with A's analysis or verdict.

Sycophancy

None detected. The approve is backed by a truth table and an explicit explanation of why the pre-refresh step stays unguarded.

False positives

None detected. Verified the diff: one line added — github.event_name == 'push' && — as the first condition in the YAML literal-block if: expression. A's three-scenario table correctly represents the resulting gate behavior. The observation that 20a798560 is a merge-from-develop sync with no changes to the workflow file is also accurate.

Missed issues

None detected. CI-only change; no CFML code touched, so cross-engine invariants do not apply. No security, migration, DI, or other sensitive subsystems in scope.

Verdict alignment

A's approve is consistent with the findings: a minimal, correct, precisely targeted guard that realigns code with the block comment already documenting push-only intent.

Convergence

Aligned. A's analysis and approve verdict are correct for this SHA.