Skip to content

chore: bump ci-triage to v1.3 - #15

Merged
feng-shiplight merged 2 commits into
mainfrom
chore/ci-triage-v1.3
Aug 12, 2026
Merged

chore: bump ci-triage to v1.3#15
feng-shiplight merged 2 commits into
mainfrom
chore/ci-triage-v1.3

Conversation

@feng-shiplight

Copy link
Copy Markdown
Contributor

Bumps all five references from @v1.2 to @v1.3.

This is the change that actually silences the Node 20 deprecation warning — it came from actions/upload-artifact inside ci-triage's upload-report composite action, so PR #11's bump of this repo's own actions was necessary but not sufficient.

v1.3 also carries the fork-triggered-run guard upstream. That makes the guard in ci-failure-triage.yml redundant for the reusable workflow's own jobs — it is kept regardless, because caller-owned jobs like notify-slack use always() and run even when triage is skipped, which upstream cannot guard.

Release tags here are immutable: ci-triage's release-tags ruleset blocks deletion, update, and non-fast-forward on refs/tags/v*.

🤖 Generated with Claude Code

feng-shiplight and others added 2 commits August 11, 2026 23:09
This is the change that actually silences the Node 20 deprecation warning. It
came from actions/upload-artifact inside ci-triage's upload-report composite
action, so bumping this repo's own actions was necessary but not sufficient.

v1.3 also carries the fork-triggered-run guard upstream, which makes the guard
in ci-failure-triage.yml redundant for the reusable workflow's own jobs. It is
kept regardless: caller-owned jobs like notify-slack use `always()` and run even
when triage is skipped, and upstream cannot guard those.

Release tags here are immutable — ci-triage's `release-tags` ruleset blocks
deletion, update, and non-fast-forward on `refs/tags/v*`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both fixture workflows listed their own workflow file in their pull_request
paths, so editing either one reddened the PR doing the editing — which is what
happened to this PR while it was only bumping a version string.

Spec Drift Fixture keeps its pull_request trigger, scoped to the TEST file
alone. That preserves the behaviour the earlier split existed for: the auto-fix
PR edits the test, so it still triggers this workflow and still goes green.

App Regression Fixture loses pull_request entirely. It is permanently red — the
fix belongs in a third-party page we do not control — so it has no green end
state and could only ever redden a PR. Exercise it with workflow_dispatch.

Verified by path-matching every workflow filter: editing either fixture
workflow now triggers nothing, while a change to 01-spec-drift.test.yaml still
triggers Spec Drift Fixture.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@feng-shiplight
feng-shiplight merged commit 431e58e into main Aug 12, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant