Repository navigation
Keep the release script from uploading the last release - #505
Merged
Merged
Conversation
Two hazards found while preparing a release, both of which bite at the moment
a release is published.
dist/ is gitignored, so it holds whatever was built last time -- on this
machine, tika-3.3.2-py3-none-any.whl and tika-3.3.2.tar.gz from August. The
script was:
python3 -m build
twine upload --verbose dist/*
so the upload would have included 3.3.2 alongside the new version. PyPI
refuses to accept a version it already has, twine stops at the first failure,
and the release ends up half done -- possibly with the new wheel never
uploaded, depending on the order twine walked the glob. The script now clears
dist/ and build/ first.
It also runs `twine check` before uploading. Invalid long-description metadata
is rejected at upload time, which on PyPI means after the sdist is already
published and the version number is burned.
The script was untracked, which is part of why this went unnoticed: a release
process that exists on one machine cannot be read or fixed by anybody else. It
is tracked now.
pypi-token is added to .gitignore. It was untracked but nothing was stopping
`git add -A` from committing it, and the file sits in the repository root
next to everything else.
chrismattmann
force-pushed
the
make-the-release-script-safe
branch
from
November 9, 2026 21:45
b536d4f to
e6f78c9
Compare
|
coverage: 70.13%. remained the same — make-the-release-script-safe into master |
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.
Two hazards found while preparing a release. Both of them bite at the moment a release is published, which is the worst time to find out.
dist/holds the last releasedist/is gitignored, so it keeps whatever was built last time. On my checkout that istika-3.3.2-py3-none-any.whlandtika-3.3.2.tar.gz, from August. The script was:python3 -m build twine upload --verbose dist/*So the upload would have included 3.3.2 alongside the new version. PyPI refuses a version it already has, twine stops at the first failure, and the release ends up half done — possibly with the new wheel never uploaded at all, depending on the order twine walked the glob. The script now clears
dist/andbuild/first.It also runs
twine checkbefore uploading. Invalid long-description metadata is rejected at upload time, which on PyPI means after the sdist is live and the version number is burned.The script was untracked
Which is part of why this went unnoticed: a release process that exists on one machine can't be read or fixed by anyone else. It's tracked now, with the reasoning in comments.
pypi-tokenAdded to
.gitignore. It was untracked, but nothing stoppedgit add -Afrom committing it, and it sits in the repository root next to everything else.Verified
Separately: the Documentation badge
It was showing failing and has gone green on its own. Nothing was broken — #502 and #503 merged 42 seconds apart, the
pagesconcurrency group superseded the first Documentation run, and GitHub renders a cancelled run as a failing badge. The next run (on #503's merge) built and deployed successfully, and the badge now readsDocumentation - passing. No change needed; worth knowing the cause, since back-to-back merges to master will do it again.