Skip to content

ci: add path-ignore and concurrency cancel before re-enabling CI#19

Merged
prodnull merged 1 commit into
mainfrom
ci/reenable-with-cost-controls
Apr 19, 2026
Merged

ci: add path-ignore and concurrency cancel before re-enabling CI#19
prodnull merged 1 commit into
mainfrom
ci/reenable-with-cost-controls

Conversation

@prodnull
Copy link
Copy Markdown
Owner

Summary

Prepares `ci.yml` for re-enable without the cost profile that made you disable it in the first place.

  • paths-ignore on both `push` and `pull_request`: `docs/`, `**.md`, `LICENSE`, `assets/`, `.github/ISSUE_TEMPLATE/`, `.gitignore`. Docs-only PRs no longer fire the full workspace CI.
  • concurrency cancel-in-progress keyed on `workflow-ref`: a force-push supersedes the prior run. One run per PR, not five.
  • workflow_dispatch added so you can manually re-trigger from the Actions tab without a no-op commit.

No job-content changes. After merge, run `gh workflow enable CI` once and the workflow is live.

Test plan

  • YAML parses (GitHub validates on push)
  • After merge + enable, next code PR fires CI
  • Docs-only PR does NOT fire CI
  • Two rapid pushes to a feature branch cancel the first run

🤖 Generated with Claude Code

The CI workflow was disabled_manually earlier when runs were flaky and
Actions minutes were tight. Re-enabling it as-is would fire the full
workspace build + clippy + test on every docs-only push and stack
billable runs on every force-push during a busy PR. Three small
triggers-block changes fix that before we flip the workflow back on:

1. paths-ignore on both push and pull_request: docs/, **.md, LICENSE,
   assets/, .github/ISSUE_TEMPLATE/, .gitignore. A docs-only PR no
   longer pays for a full code CI run. Code changes still trigger
   normally.

2. concurrency group keyed on workflow + ref with cancel-in-progress
   true. A force-push to a PR branch supersedes the prior run instead
   of stacking it. On a PR with 5 force-pushes, you pay for one run,
   not five.

3. workflow_dispatch added so the workflow can be re-triggered
   manually from the Actions tab without needing a no-op commit.

No changes to job content, so fmt/clippy/test coverage is unchanged
once this lands and the workflow is re-enabled via `gh workflow enable
CI`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@prodnull prodnull merged commit 80e294e into main Apr 19, 2026
1 check passed
@prodnull prodnull deleted the ci/reenable-with-cost-controls branch April 19, 2026 16:06
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