Let a release be cut from the Actions tab, tag included - #160
Merged
Conversation
The workflow could only be started by pushing a tag from a working copy, which makes releasing depend on whoever has a clone and the right credentials. Running it from the Actions tab now cuts the whole release, creating the tag itself via the releases API. Creating the tag *after* the build is the better order regardless of who starts it: the tag lands on a commit that has already had its version guards checked, its metadata strict-checked, and its wheel installed clean and made to solve an instance. A tag pushed first is a promise the build has not been asked to keep yet. A TestPyPI dry run still creates neither tag nor release -- it is there to rehearse, not to leave traces. Practical note for anyone working in a sandbox: this environment's git proxy returns 403 on `git-receive-pack` for tag refs while allowing branch pushes, so a tag cannot be pushed from here at all. The Actions path is not a workaround bolted on for that -- it is what "release directly from GitHub Actions" should have meant in the first place -- but it is what makes the release reachable without a laptop. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Meb35zHKsyBkH2sbWoyKMT
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
Contributor
|
Tick the box to add this pull request to the merge queue (same as
|
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.
Follow-up to #158. The release workflow could only be started by pushing a tag from a working copy, which makes releasing depend on whoever happens to have a clone and the right credentials.
What changes
Actions → release → Run workflow → target:
pypinow cuts the whole release, creating the tag itself through the releases API.Creating the tag after the build is the better order regardless of who starts it: the tag lands on a commit that has already had its version guards checked, its metadata strict-checked, and its wheel installed clean and made to solve an instance. A tag pushed first is a promise the build has not been asked to keep yet.
Pushing a tag still works and runs the identical pipeline. A TestPyPI dry run deliberately creates neither tag nor release — it is there to rehearse, not to leave traces.
Why now
I tried to push
v2.3.0and could not: this sandbox's git proxy returns HTTP 403 ongit-receive-packfor tag refs while allowing branch pushes, and the GitHub MCP tooling here exposes only read operations for tags and releases. So the tag was unreachable from my side entirely.That is my constraint, not yours — but it surfaced a real gap. "Release directly from GitHub Actions" should not have required a local
git push --tagsin the first place.Still blocked on you
The
pypijob cannot succeed until a trusted publisher exists on PyPI. From #158:APLA-ToolboxPythonPDDLrelease.ymlpypihttps://pypi.org/manage/project/jupyddl/settings/publishing/
Once that exists, one click on Run workflow →
pypipublishes 2.3.0, tags it, and cuts the release. I would suggest atestpypirun first — configure the same publisher on https://test.pypi.org with environmenttestpypi— because a first publish is the one you least want to fumble.Generated by Claude Code