Repository navigation
ci: keep the repository's own settings out of the release notes - #746
Merged
Merged
Conversation
.tf/ describes how GitHub is configured, not what wikven does, so a change there belongs in no release. It reached one as a feature in #744, which release-please read the way it was labelled. exclude-paths drops a commit whose every file is under the path, so the type it carries stops mattering. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn
lens0021
enabled auto-merge (squash)
September 10, 2026 15:37
lens0021
added a commit
that referenced
this pull request
Sep 10, 2026
`.tf/` was excluded in #746 because a release does not deliver it. `docs/` is the same case for a different reason: `deploy-docs.yml` publishes it the moment a change reaches `main`, so by the time a version is tagged that change has been live on the site for days. A release has nothing to claim there, whatever type the commit carries. ## Nothing moves Of the commits since 1.0.0 that touch `docs/` and nothing else, thirteen are `docs:` and one is `build(deps)`. Both are already hidden and neither bumps, so the pending 1.1.0 reads exactly as it does now. This only closes the gap a mislabelled commit would go through — which is the gap #744 went through. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn --- _Generated by [Claude Code](https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn)_ Co-authored-by: Claude <noreply@anthropic.com>
lens0021
added a commit
that referenced
this pull request
Sep 10, 2026
There already is a check for this. `semantic-pull-request.yml` carries a second job that refuses `feat:` and `fix:` on a pull request touching nothing but documentation, for exactly the reason #744 turned out to matter: the title becomes the squash commit's subject, and release-please reads it. #744 went through it twice over. **Its list was too narrow.** It read `docs/`, `*.md` and `LICENSE`. A ruleset under `.tf/` is none of those, so the job said the change was wikven's own and let `feat:` stand. Widened here to everything that is the repository rather than the program — the two above plus `.tf/` and `.github/`. **It could not have blocked anything anyway.** The job is not in the required checks, so a red result leaves the pull request mergeable, and auto-merge would have merged it regardless. Added to the list in `.tf/ruleset.tf`. Renamed `docs-only` → `repository-only`, since it no longer reads only documentation, and the required check has to name it. #746 and #747 gave release-please `exclude-paths` for `.tf` and `docs`. That is a net under the mistake: the commit is dropped silently, and nobody learns anything. This is where it gets caught and said out loud, which is also why the check's list is wider than `exclude-paths` — the latter can only name directories, so `*.md` and `LICENSE` cannot appear in it. ## Exercised The job's own script, lifted out of the workflow with `gh api` stubbed, against ten pull requests: | title | files | result | | --- | --- | --- | | `feat: …` | `.tf/ruleset.tf` | refused | | `feat: …` | `.github/workflows/a.yml` | refused | | `feat: …` | `docs/a.wikitext`, `README.md` | refused | | `feat: …` | `LICENSE` | refused | | `fix(build): …` | `.tf/ruleset.tf` | refused | | `feat!: …` | `.tf/ruleset.tf` | refused | | `feat: …` | `includes/A.php` | allowed | | `feat: …` | `docs/a.wikitext`, `includes/A.php` | allowed | | `docs: …` | `.tf/ruleset.tf` | allowed | | `ci: …` | `.tf/ruleset.tf` | allowed | Run locally, and it has to be: the workflow triggers on `pull_request_target`, which runs the version on the base branch. The check reporting on this pull request is `docs-only` from `main` — the widened job first runs on whatever comes after this. The same goes for the required-check entry, which needs a `tofu apply`; until then `repository-only` reports without blocking. Two consequences of that worth knowing about. Between merging and applying, `docs-only` no longer exists while nothing requires `repository-only`, so for that window neither name blocks. And this pull request cannot check its own title — it touches only `.github/` and `.tf/`, so `ci:` is what the new rule would allow, but the rule is not the one that ran. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#744 landed as
feat:. It is not one:.tf/says how GitHub is configured, and a reader of the release notes has no wiki that behaves differently for it. release-please read the label it was given and put it under Features in #618.What can and cannot be corrected
A merged commit's type cannot be changed —
maintakes no rewrite, and release-please offers nothing that retypes an earlier commit.Release-As:is the one footer that reaches back, and it would change nothing here anyway: ten otherfeat:commits since 1.0.0 already settle the minor bump, so 1.1.0 is 1.1.0 either way. The mistake cost a changelog line, not a version.What the configuration does offer is
exclude-paths, which drops a commit whose every file sits under one of the named paths — before the type is ever read. So this is not a correction of one commit but of the rule that let it through: nothing under.tf/reaches a release again, however it is labelled.Effect
release-please re-reads the range on every run, so #618 loses the entry on the next one. Of every commit since 1.0.0, exactly one touches nothing but
.tf/— #744 — so that is the only line that moves.🤖 Generated with Claude Code
https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn
Generated by Claude Code