Publish to PyPI CI jobs fails

[ev-br]

Following the relase workflow at https://data-apis.org/array-api-compat/dev/releasing.html, uploading to PyPI from CI fails with (here's the failing job: https://github.com/data-apis/array-api-compat/actions/runs/12495361002/job/34866045408)

Run pypa/[email protected]
Run # Reset path if needed
Run # Set repo and ref from which to run Docker container action
Run # 🔎 Discover pre-installed Python
python-path=/usr/bin/python3
Run # Create Docker container action
Run ./.github/.tmp/.generated-actions/run-pypi-publish-in-docker-container
/usr/bin/docker run --name ghcriopypaghactionpypipublishv1[12](https://github.com/data-apis/array-api-compat/actions/runs/12495361002/job/34866045408#step:6:13)3_48e5e9 --label 298623 --workdir /github/workspace --rm -e "INPUT_USER" -e "INPUT_PASSWORD" -e "INPUT_REPOSITORY-URL" -e "INPUT_PACKAGES-DIR" -e "INPUT_VERIFY-METADATA" -e "INPUT_SKIP-EXISTING" -e "INPUT_VERBOSE" -e "INPUT_PRINT-HASH" -e "INPUT_ATTESTATIONS" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY"
Checking dist/array_api_compat-1.10.0-py3-none-any.whl: PASSED
Checking dist/array_api_compat-1.10.0.tar.gz: PASSED
Notice: Generating and uploading digital attestations
Fulcio client using URL: https://fulcio.sigstore.dev
TUF metadata: /root/.local/share/sigstore-python/tuf/https%3A%2F%2Ftuf-repo-cdn.sigstore.dev
TUF targets cache: /root/.cache/sigstore-python/tuf/https%3A%2F%2Ftuf-repo-cdn.sigstore.dev
Found and verified trusted root
Generating ephemeral keys...
Requesting ephemeral certificate...
Retrieving signed certificate...
Found <Name(O=sigstore.dev,CN=sigstore-intermediate)> as issuer, verifying if it is a ca
attempting to verify SCT with key ID dd3d306ac6c71132[63](https://github.com/data-apis/array-api-compat/actions/runs/12495361002/job/34866045408#step:6:69)191e1c99673702a24a5eb8de3cadff878a72802f29ee8e
Successfully verified SCT...
Error: Attestation generation failure: /github/workspace/dist/array_api_compat-1.10.0.tar.gz already has a publish attestation: /github/workspace/dist/array_api_compat-1.10.0.tar.gz.publish.attestation

I wonder if it's related to that the 1.10 tag is not GPG signed (can do going forward) or there are some tokens/permissions to set up.

For now I pushed 1.10 manually.

Going forward, it'd be nice to figure out what's missing in the CI workflow. Would you help me out @asmeurer ?

[ev-br]

1. Looking at the GH releases (automatically created on a git push upstream 1.10), there are some .attestation files for 1.10 but not for 1.9.1.

2. Not entirely sure what's needed to update the package on conda-forge

[ev-br]

Also, I cannot update the main branch now: #219 or any other PR is blocked by the failed upload, and pushing to main directly is blocked by the branch protection.

[asmeurer]

This is discussed here pypa/gh-action-pypi-publish#283.

[lucascolley]

I'm happy to help with conda-forge

[lucascolley]

FWIW the release workflow I use for array-api-extra seems less error prone - the only manual part is publishing a new release on the GitHub GUI.

[rgommers]

conda-forge is merged already. A bot opens a PR, and it gets auto-merged if CI is green.

[ev-br]

This is discussed here pypa/gh-action-pypi-publish#283.

Thanks! So the solution is to disable publishing to TestPyPI? Not sure I follow all the fine points in that discussion.

[rgommers]

I think this is solved after gh-222, no changes needed, right? The TestPyPI upload should not fail next time if CI has already run on the release PR once the release tag is pushed.

[ev-br]

Yeah, an immediate problem's fixed. The upload failure modes are a bit of a mystery, but that's for next time. Thanks for all the help Ralf!