mirror of https://github.com/alexbelgium/hassio-addons.git synced 2026-09-10 19:59:09 +02:00

Files

Alexandre 948a2722f3 fix(ai): let the fix step own config.yaml, and require the patch-counter bump (#2973 )

* fix(ai): let the fix step own config.yaml, and require the patch-counter bump

The premise that the fix step cannot touch config.yaml turned out to be wrong,
and the real problem was the opposite of what it looked like.

config.yaml was already in scope — issue-fix.md lists it among the files the
sweep reads and owns, and all three merged ai-fix PRs edited it. What they
edited, though, was the one thing hard limit 2 forbade outright:

  PR #2970  qbittorrent  version: "5.2.3.2" -> "5.2.3.3"
  PR #2912  bazarr       version: "1.6.0.1" -> "1.6.0.2"

Both bumped only the LOCAL PATCH COUNTER, leaving the upstream X.Y.Z alone —
i.e. exactly the right thing, in direct violation of the written rule. Nothing
enforces that rule (ai_guard_paths.sh only covers .github/ and .templates/), so
it has been quietly contradicted by practice, and it also contradicts CLAUDE.md's
own PR requirement to bump version.

It matters because Supervisor will not offer a rebuild without the bump: a fix
merged without one ships inert while the issue looks closed. That is the worst
outcome available — worse than not fixing it.

So the carve-out is narrowed to what addons_updater actually owns (the
`upstream` field and the upstream X.Y.Z), and bumping the trailing .N is now
required rather than forbidden, with the dot-not-hyphen trap called out
(X.Y.Z-N reads as a semver pre-release and Supervisor treats it as older).
Exotic version shapes — LSIO tags, dates, nightlies — are explicitly left alone
rather than guessed at.

Applied to all four places the rule is stated so they cannot drift:
issue-fix.md, issue-execute-plan.md, CLAUDE.md, and pr-coderabbit.md — the last
keeps the restriction, since it amends a PR whose single bump already covers it,
but now says why instead of reading as a contradiction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ai): derive the patch counter from updater.json, not from version's shape

Six review findings, all reproduced against the repo before accepting.

Codex (P1) — the rule "increment the trailing .N" is wrong for most of this
repo, because you cannot tell a local counter from an upstream component by
looking at `version`. Checked all 134 add-ons:

  version == upstream_version (no counter, must APPEND .1):  82
  version == upstream_version + .N (counter, INCREMENT):      8
  version drifted from upstream (LEAVE ALONE):               36
  no usable updater.json (LEAVE ALONE):                       8

So the previous wording would have mutated updater-owned data on 82 add-ons:
sonarr's 4.0.19.3001 IS the upstream version, and incrementing it to
4.0.19.3002 burns the identifier of a future real release; linkwarden's 2.16.0
would have become 2.16.1, indistinguishable from an upstream minor bump.

updater.json's upstream_version is now the authority: append .1 when version
equals it, increment only the digits that follow it, otherwise leave version
alone. Validated by running the rule as written over every add-on — 0
violations of the invariant that a bumped version must still start with
upstream_version.

Copilot — there is no `upstream:` key in any config.yaml (0 of 134); upstream
tracking lives in updater.json as upstream_repo / upstream_version. That was
inherited text naming a field that does not exist, in all four places. Replaced
with the real constraint: never edit updater.json.

Copilot — the "a workflow step enforces them" headers over-claimed. Only limit
1 is machine-enforced (ai_guard_paths.sh); the rest ship silently if broken,
which is worth saying plainly given limit 2 has been quietly contradicted by
practice for months.

Copilot — Outcome B produces a plan and no PR, so "say so in the pull request
body" had no place to land. Now covers both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

2026-08-15 19:14:29 +02:00

2.5 KiB

Raw Permalink Blame History

Address CodeRabbit's review — one-shot

CodeRabbit reviewed an AI-authored pull request. You are checked out on that PR's branch (ai-fix/<addon>-<issue>). Your job, in a single pass: read CodeRabbit's feedback and either fix each actionable point or reply saying why it doesn't apply. This runs once — CodeRabbit re-reviewing your pushed fix will not trigger you again.

The PR number is in your prompt. Set PR to it.

Gather the feedback

Review summaries and verdicts: gh pr view "$PR" --json reviews,title,body,files
Inline (line-level) comments — this is where CodeRabbit's concrete suggestions live: gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR}/comments" --paginate Each has path, line, body, and an id (needed to reply).

Consider only comments authored by coderabbitai[bot]. Ignore its collapsed "nitpick"/"outside diff" noise unless the point is real.

Hard limits (a workflow step enforces the first)

Never modify .github/ or .templates/. Repo-wide infrastructure.
Leave version in config.yaml alone, and never edit updater.json. The rest of config.yaml is fair game. Unlike the fix sweep, you are amending a pull request that has already bumped the local patch counter — one bump covers the whole PR, so incrementing it again here would just churn the diff.
Stay within this PR's scope and branch. Do not open a new PR, do not touch other add-ons, do not merge, do not mark ready/draft.

For each actionable comment

Fix it when it's a real correctness, safety, or clarity improvement within scope: make the minimal edit, run shellcheck on any shell you change, and if behaviour changed update the add-on's CHANGELOG.md entry.
Decline it when it's wrong, out of scope, or a style nit that fights the add-on's conventions: reply to that specific comment with one sentence of reasoning: gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR}/comments/<id>/replies" -f body='...'

Finish

If you changed anything: stage, commit with a short message (fix: address CodeRabbit review), and push to the PR branch (git push origin HEAD).
Post one summary comment on the PR (gh pr comment "$PR" --body '...') listing what you fixed and what you deliberately left, in plain language. End with a note that this is automated and pending @alexbelgium's review.
If nothing was actionable, post a one-line comment saying so and stop. Do not invent changes to look busy.

2.5 KiB Raw Permalink Blame History