A CI job failed for 6e25af8a721a9d8507745efad3d15dae75b78909 on the "Upload wheels" step with this error:
#!/bin/bash --login -eo pipefail
if [[ "$CIRCLE_TAG" == v* ]]; then
# We're building a release tag so we should probably really
# release it!
repo="pypi"
else
# We're building anything else. Exercise as much of the release
# code as possible - but send it to the "test" package index,
# not the "real" one.
repo="testpypi"
TWINE_PASSWORD="$TWINE_TESTPYPI_PASSWORD"
fi
python -m twine upload --repository $repo dist/*
Uploading distributions to https://test.pypi.org/legacy/
Uploading python_challenge_bypass_ristretto-2021.7.13.dev12-py2.py3-none-macosx_10_14_x86_64.whl
100% 265k/265k [00:00<00:00, 763kB/s]
NOTE: Try --verbose to see response content.
HTTPError: 400 Client Error: File already exists. See https://test.pypi.org/help/#file-name-reuse for more information. for url: https://test.pypi.org/legacy/
Exited with code exit status 1
CircleCI received exit code 1
This seems to be because the linear versioning scheme can produce the same version number in different branches. If it does and if CI runs for both of those branches on each of those revisions then it will try to upload two wheels with the same version number (in the case above, 2021.7.13.dev12).
This should only affect testpypi uploads since real release uploads should always have distinct version numbers derived from a new release tag. However, it does cause mostly-spurious failures on CI, including on master CI runs, and it would be nice to avoid those.
A CI job failed for 6e25af8a721a9d8507745efad3d15dae75b78909 on the "Upload wheels" step with this error:
This seems to be because the linear versioning scheme can produce the same version number in different branches. If it does and if CI runs for both of those branches on each of those revisions then it will try to upload two wheels with the same version number (in the case above, 2021.7.13.dev12).
This should only affect testpypi uploads since real release uploads should always have distinct version numbers derived from a new release tag. However, it does cause mostly-spurious failures on CI, including on master CI runs, and it would be nice to avoid those.