ci: pin yamllint where Dependabot can see it - #336
Merged
Conversation
The version sat in a pipx install line, which no package manager reads, so it was one of the pins nothing was watching. A uv dependency group is a manifest Dependabot already knows how to bump, and the lockfile pins yamllint's own dependencies too, which the pipx install resolved fresh on every run. Follows chaotic-ground/setup-mago#14. The other two loose pins, taplo and updatecli, stay manual: both live in a workflow "with:" input, and updatecli's yaml target reformats the file it edits -- it drops blank lines and halves the space before a comment, which yamllint --strict then rejects. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qiZSGWHrxkjvFxA8swynp
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
lens0021
marked this pull request as ready for review
August 15, 2026 13:11
lens0021
added a commit
that referenced
this pull request
Aug 15, 2026
Both statuses were `informational: true`, which is the "never fail" setting, so the only thing Codecov did was post a comment on every pull request. This turns the comment off and gives both statuses something they can actually fail on. ## Where the numbers come from Codecov's app and API are not reachable from here, but the `codecov/patch` check run records the project total as its `auto` target, so the history is readable off GitHub: | PR | date | check output | |---|---|---| | [#226](#226) | 2026-07-19 | `0.00% of diff hit (target 13.62%)` | | [#285](#285) | 2026-08-12 | `34.75% of diff hit (target 19.25%)` | | [#326](#326) | 2026-08-15 | `0.00% of diff hit (target 24.90%)` | So the project total is around 25%, and it moved five points in three days. `maintenance/` is 2561 of the 4932 PHP lines outside `tests/`, and it is essentially all uncovered — #326 was six lines of `maintenance/buildTranslations.php` at 0%, and #285's misses were 74 in `storeWebfonts.php`, 9 in `rewriteScripts.php`, 2 in `buildScripts.php`, 1 in `build.php`. That is what holds the total at 25%, and it is why an absolute project target is the wrong instrument: any number above today's coverage fails immediately, and any number below it stops being a check the moment coverage rises. ## What the config does now **Project — `target: auto`, `threshold: 2%`.** Compare against the pull request's base rather than a fixed line, and allow a two-point dip. The allowance is sized to the thing that legitimately moves the total: a new maintenance script of 200-400 lines at 0% coverage costs roughly 1-2 points with nothing having regressed. A real regression is much larger — dropping the tests for one mid-sized class under `includes/` is worth four or five points, well past the allowance. The trade-off is honest: losing coverage of one *small* class (~40 statements, ~1.8 points) would slip through. Tightening to 1% closes that but fails on the next maintenance script, which is the failure mode you asked me to avoid. Note that `removed_code_behavior` is left at its `adjust_base` default, so deleting covered code does not itself count as a regression. **Patch — `target: 70%`, scoped to `includes/`.** A patch target applied to the whole tree can never pass on a `maintenance/`-only change — #326 would have failed at any target above zero. Restricting the status to `includes/` makes it a real bar for the code that is actually unit-testable, and leaves script changes alone (Codecov passes a status whose paths the diff does not touch). Checked against history: #285 would pass, since its `includes/` lines were 42/43 in `Webfonts.php` plus 0/5 in `WikvenSettings.php`, or 87.5%; #326 and #336 touch no `includes/` lines and pass trivially. 70% rather than something higher leaves room for a couple of uncovered guard clauses. The known annoyance is a very small `includes/` diff — four lines with two uncovered is 50% and fails — so 60% is the knob if that shows up in practice. I did not add an `ignore:` block for `maintenance/`. It would raise the reported total sharply and make the patch scoping unnecessary, but it also changes what the README badge means, which is a bigger call than this change. ## The project status has never actually existed Worth knowing before relying on it: **`codecov/project` has never appeared on this repository**, on any surface, at any point since coverage was introduced. Checked both GitHub surfaces, because they are different lists: - **Check runs** (`GET /commits/{sha}/check-runs`) on #226, #285, #321, #326, #336 and this pull request: `codecov/patch` every time, `codecov/project` never. - **Commit statuses** (`GET /commits/{sha}/status`) on #226, #285, #326, #336 and this pull request: `total_count: 0` — this repository has no commit statuses at all. Codecov here posts through the Checks API only, so nothing was hiding on the other endpoint. What that rules out: - **Not `informational`.** Both statuses carried it, and patch posted anyway. - **Not a missing base report or an unresolvable total.** The patch status's `auto` target *is* the base commit's project coverage, and it has resolved to a real number every time (13.62%, 19.25%, 24.90%). Codecov computes this repository's project coverage on every pull request — it simply never publishes a status for it. - **Not the `fixes:` rewrite or the upload shape.** Per-file patch coverage resolves to real repository paths, so the path rewrite and the clover upload are both working. - **Not branch protection.** Protection can require or hide a check, but it cannot stop one being created, and no `codecov/project` is ever created. Also consistent: no Codecov comment on this repository has ever carried a project-coverage line — every one of them reports diff coverage only. Project-level output appears to be switched off account-side rather than repository-side, which would explain the status and the comment together. That leaves causes outside this file, and both need the Codecov dashboard to confirm — see the review thread. Until then the `project` block here may simply be inert, and `codecov/patch` is the status that actually enforces anything. ## Verification - `uv run --frozen --group lint yamllint --strict .` passes. - No workflow touched, so no `zizmor` run. - **The comment is gone.** Codecov reported on this pull request — `codecov/patch` is green with `Coverage not affected` — and posted no comment, where #226, #285, #321, #326 and #336 each got one. That is the change working, not just parsing. - **Not verified: the targets themselves.** This pull request changes no PHP, so nothing exercised the 2% threshold or the 70% patch bar. Codecov also generally reads its config from the base branch for a comparison, so the numbers are unproven until something with PHP in it lands on top of this. - **Not verified: the schema.** Codecov's own validator (`POST https://codecov.io/validate`) is blocked by this environment's egress proxy, and `app.codecov.io` is unreachable, so the config was never checked against Codecov's parser. 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.
Applies chaotic-ground/setup-mago#14 here — the same
pipx install yamllint==1.38.0line was inlint.yml.The version moves into
pyproject.toml, which Dependabot'suvecosystem reads.uv.lockcomes with it, so yamllint's own dependencies (pyyaml,pathspec) are pinned too —pipx installresolved those fresh on every run. setup-uv is v10.0.1 rather than setup-mago's v9.0.0; Dependabot will converge them.The pin inventory this came out of
Looking for others like it, six versions in this repo are invisible to a package manager:
v0.6.1DockerfileARG1.46.0composer.jsonextra2.5.8biome.json$schema1.38.0lint.ymlpipx install0.10.0lint.ymlwith:v0.120.1updatecli.ymlwith:TRANSLATE_VERSIONandULS_VERSIONareREL1_46, a MediaWiki release branch being followed on purpose, so they are not pins.Why taplo and updatecli stay manual
Both live in a workflow
with:input, which needs updatecli'syamltarget — and that target reformats the whole file. Applied tolint.ymlit drops every blank line and halves the two spaces before each# vXcomment, whichyamllint --strictthen rejects:Same failure mode as the
jsontarget oncomposer.json(#334). This is not a local quirk: the officialghcr.io/updatecli/policies/updatecli/githubactionpolicy uses exactly thatyamltarget, so the published policy for updatecli's own pin would break this repo too.A
file-target regex would work — backreferences are supported — but it has to anchor across the indentation and the# v2comment to stay unique, which is the kind of brittle hand-written pattern worth avoiding for two pins that move about twice a year.Verified locally
uv lockresolves 4 packages;uv run --frozen --group lint yamllint --versionreports1.38.0, andyamllint --strict .passes on the tree.taplo fmt --checkandtaplo checkpass withpyproject.tomladded.uv.lockis not matched by taplo's**/*.tomlinclude, so it is not linted.biome ciis unchanged — its one warning is pre-existing, in CSS this branch does not touch..venv/is gitignored.Generated by Claude Code