chore(release): 0.2.0 - #51
Merged
Merged
Conversation
Ten open issues closed this pass, and the theme running through them is worth naming in the changelog rather than only in the individual entries: several documented capabilities were declared and never wired up -- an entry-point group nothing read, a descriptor format nothing loaded, an inference feature with no inference -- and several rules reported the opposite of what had happened. Version synchronised across pyproject, CITATION.cff and the CHANGELOG, with a test that they agree. ToolTrace Bench shipped with those three saying three different things, two of them describing a version that had never been tagged; it is a one-line fix every release, which is exactly what a test is for. Confirmed it fails when they drift. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Two things that would have made the first tag fail, both found by pushing a tag on a sibling repo rather than by reading the file. `gh release create` shells out to git for the repository context, and the GitHub Release job had no checkout. On local-ai-hardware-bench's first ever tag this produced "fatal: not a git repository" after the build, SBOM and checksums had all succeeded -- no release object, nothing published, the tag simply produced nothing. Same job shape here. ToolTrace Bench's equivalent does check out, which is why it is the only one of these repos that has shipped a release. The PyPI upload was unconditional. It needs a Trusted Publisher registered for this project on pypi.org, which is a form on the account that owns the name and cannot be created from a repository. Without a guard the job fails on every tag even when everything else succeeded, and a red release is indistinguishable from a broken one. Now it skips with a notice naming exactly what to register; set PUBLISH_ENABLED=true once it exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
API Verity — contract reviewOne comment per PR — updated on each push. |
webdevsamran
added a commit
that referenced
this pull request
Sep 7, 2026
* chore(release): 0.2.0 Ten open issues closed this pass, and the theme running through them is worth naming in the changelog rather than only in the individual entries: several documented capabilities were declared and never wired up -- an entry-point group nothing read, a descriptor format nothing loaded, an inference feature with no inference -- and several rules reported the opposite of what had happened. Version synchronised across pyproject, CITATION.cff and the CHANGELOG, with a test that they agree. ToolTrace Bench shipped with those three saying three different things, two of them describing a version that had never been tagged; it is a one-line fix every release, which is exactly what a test is for. Confirmed it fails when they drift. * fix(release): check out in the release job, and guard the PyPI upload Two things that would have made the first tag fail, both found by pushing a tag on a sibling repo rather than by reading the file. `gh release create` shells out to git for the repository context, and the GitHub Release job had no checkout. On local-ai-hardware-bench's first ever tag this produced "fatal: not a git repository" after the build, SBOM and checksums had all succeeded -- no release object, nothing published, the tag simply produced nothing. Same job shape here. ToolTrace Bench's equivalent does check out, which is why it is the only one of these repos that has shipped a release. The PyPI upload was unconditional. It needs a Trusted Publisher registered for this project on pypi.org, which is a form on the account that owns the name and cannot be created from a repository. Without a guard the job fails on every tag even when everything else succeeded, and a red release is indistinguishable from a broken one. Now it skips with a notice naming exactly what to register; set PUBLISH_ENABLED=true once it exists. ---------
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
1 participant
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.
Cuts 0.2.0. Ten issues closed this pass — #15 through #24.
The changelog names the theme running through them, because it is more useful than ten separate entries: several documented capabilities were declared and never wired up (an entry-point group nothing read, a descriptor format nothing loaded, an inference feature with no inference), and several rules reported the opposite of what had happened (a field becoming required classified as optionalized at INFO; a unary RPC becoming bidirectional producing zero changes).
Version synchronised across
pyproject.toml,CITATION.cffand the CHANGELOG, with a test that they agree — ToolTrace Bench shipped with those three saying three different things, two describing a version that had never been tagged. Confirmed the test fails when they drift.pytest 81.16% ✅ · e2e ✅ · ruff ✅