ci: gate the starter install shape, and source release notes from the changelog - #37
Merged
Merged
Conversation
The clean-environment job installs all six packages with EVERY extra, so agentship-observability is always present. That is why it passed on 0.0.1: the bug was that `provider` defaults to "otel" and every agent is traced, so a stack WITHOUT the adapter could not run any agent at all. A job that always installs the adapter cannot see it. `--help` and an import passed too. Only running an agent found it, and only in the minimal shape -- which nothing in CI installed. So the job now also builds `pip install "agentship-sdk[starter]"` as a new user gets it, and runs the README quickstart with the provider keys empty. Two supporting details: Siblings install by explicit FILE PATH, not --find-links. With the same version already on PyPI, pip prefers the published wheel over the local one and silently tests the wrong build -- exactly what happened while verifying this change by hand, where the "release candidate" under test turned out to be the broken 0.0.1 from the index. And a guard fails the job if agentship-observability ever appears in that environment, because the step would then be quietly testing the same shape as the job above it and proving nothing. Verified both directions, which is the part that matters: against wheels built from this branch the quickstart prints `echo: hi there` and the job passes; against the published 0.0.1 it prints `observability provider 'otel' is not installed` and the job fails. The gate reproduces the escape it exists to prevent. 779 passed, 14 skipped, 3 xfailed. Lint clean. ci.yml parses.
The releases page is empty and would have stayed low-value: `github-release` published with `--generate-notes` alone, which writes the page from PR titles. That is a list of what was merged, not a description of what changed, and it lives nowhere a reader can find later. So the release page becomes a copy of docs/CHANGELOG.md rather than a second account of the same release. `scripts/changelog.py` extracts the `## [<version>]` section; the workflow publishes it as the release body and appends the generated commit list underneath for anyone who wants the detail. The `build` job now runs `changelog.py --check` before anything is published. A tag with no notes fails while it is still free to fix -- after six uploads the version is burned and the page is already public. Also drew the version boundary the changelog never had. It was written when the project had cut no releases, so everything sat under [Unreleased] -- but that work shipped IN 0.0.1. Marked it as such (117 lines, YANKED, with what yanking means), leaving 0.0.2 to say the one thing that is actually new: an agent runs without the observability adapter installed. Verified: --check passes for 0.0.2 and 0.0.1, exits 1 with an actionable message for a version with no section, and --section prints the 29 lines the page will show. Both workflows parse. mkdocs --strict clean. 779 passed, 14 skipped, 3 xfailed. Lint clean.
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.
The two commits that did not make it into #36 — its head was still
fc83c0ewhen it merged.ci: install the shape a new user gets, and run an agent in itThe clean-environment job installs all six packages with every extra, so
agentship-observabilityis always present. That is why it passed on0.0.1: the bug wasthat a stack without the adapter could not run any agent, and no job in CI ever built that
stack.
--helpand an import passed too — only running an agent found it.The job now also installs
agentship-sdk[starter]as a new user gets it and runs the READMEquickstart with the provider keys empty. Siblings install by explicit file path, because
with the same version on PyPI pip prefers the published wheel and silently tests the wrong
build — which happened while verifying this by hand. A guard fails the job if the adapter
ever appears in that environment, since the step would then prove nothing.
Verified both directions: against wheels from this branch the quickstart prints
echo: hi thereand the job passes; against the published0.0.1it fails withobservability provider 'otel' is not installed.docs: make the changelog the source of the GitHub release notesgithub-releasepublished with--generate-notesalone — a list of PR titles rather than adescription of what changed.
scripts/changelog.pynow extracts the## [<version>]sectionand the workflow publishes it as the release body, with the generated commit list appended.
buildrunschangelog.py --checkbefore anything is published, so a tag with no notesfails while it is still free to fix.
Also drew the version boundary the changelog never had: it was written before any release, so
everything sat under
[Unreleased]— but that work shipped in0.0.1. Marked as such,leaving
0.0.2to say the one thing that is new.Verification
779 passed, 14 skipped, 3 xfailed · ruff clean ·
mkdocs build --strictclean · both workflowsparse ·
changelog.py --checkpasses for 0.0.2 and 0.0.1 and exits 1 with an actionablemessage for a version with no section.