Repository navigation
fix(sentry): stop one build reporting two release strings - #3416
Open
vpetersson-bot wants to merge 1 commit into
Open
vpetersson-bot wants to merge 1 commit into
vpetersson-bot wants to merge 1 commit into
Conversation
The release CalVer is zero-padded on purpose (2026.09.0, matching the git tag), and every consumer that needs strict semver unpads it — uv.lock stores 2026.9.0, render_balena_yml.sh normalises before stamping balena.yml. get_anthias_release does it on only one of its two paths: the build backend normalises per PEP 440 on the way into package metadata, so importlib.metadata answers 2026.9.0, while the pyproject.toml fallback hands back the padded string verbatim. Sentry keys releases by string, so the same image arrives as two unrelated releases — 2026.9.0+fa2d90a and 2026.09.0+fa2d90a are both on record for one build. "Resolved in release X" and the regression detection built on it then only see whichever half an event landed in, which is the one thing a release stamp exists to prevent. The split also reaches the System Info page, the v2 info API and the outbound User-Agent. Unpad in get_anthias_release so both paths land on the side the rest of the toolchain already takes. Anything that is not an all-numeric dotted version is returned untouched rather than guessed at. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
|
This branch has not been deployed
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
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.
Issues Fixed
No tracked issue — found while auditing the Sentry project. Sentry
holds
2026.9.0+fa2d90aand2026.09.0+fa2d90aas two separatereleases of one build (same git short hash), and the older
2026.06.3alongside2026.6.3.Description
The release CalVer is zero-padded on purpose (
2026.09.0, matchingthe git tag
v2026.09.0), and every consumer that needs strictsemver unpads it:
uv.lockstores2026.9.0, andbin/render_balena_yml.shnormalises the same way before stampingbalena.yml, which rejects a padded segment.get_anthias_release()unpads on only one of its two paths. Thebuild backend applies PEP 440 normalisation when it copies the
version into the package metadata, so
importlib.metadata.version()answers
2026.9.0; thepyproject.tomlfallback — the path everyimage takes, since
uv sync --no-install-projectleaves nodistribution to read — returns the padded string verbatim. One build
therefore describes itself two ways depending on how it was
deployed.
Sentry keys releases by string, so that splits a single image into
two unrelated releases. "Resolved in release X" and the regression
detection built on top of it can then only reason about whichever
half an event landed in — the exact thing a release stamp exists to
prevent. The same split reaches the System Info page, the v2 info
API and the outbound User-Agent.
This unpads in
get_anthias_release()so both paths land on the sidethe rest of the toolchain already takes. It is the whole of what PEP
440 normalisation does to a version of this shape. Anything that is
not an all-numeric dotted version is returned untouched rather than
guessed at. The checked-in CalVer stays zero-padded, so the release
runbook does not change.
tests/test_version.pyis new — there was no direct coverage of thishelper, every other suite mocks it. Two of its cases fail without the
one-line change in
version.py.Checklist
Not device-tested: the change is a pure string normalisation in a
version helper, exercised by unit tests on both resolution paths, with
no board-specific behaviour to observe on hardware.
🤖 Generated with Claude Code