Getting Token request failed with trusted publishing

[briemla]

Hi,

we want to use the gh-action-pypi-publish in our github workflows to publish the packages to pypi and testpypi. Unfortunately, this does not work and I do not know what is wrong.

Our workflow file can be found here: https://github.com/OpenTrafficCam/OTAnalytics/blob/main/.github/workflows/release-testpypi.yml

The trusted publisher on testpypi contains the following information:
Repository: OpenTrafficCam/OTAnalytics
Workflow: release-testpypi.yml
Environment name: testpypi

The environment testpypi is configured in github and provides the environment variable PYPI_REPO_URL with the value https://test.pypi.org/legacy/

The last failed workflow run can be found here: https://github.com/OpenTrafficCam/OTAnalytics/actions/runs/13286224589

Is there any configuration option we missed?

Best regards,
Lars

[webknjaz]

Configure matching Trusted Publisher within TestPyPI.

[webknjaz]

@woodruffw should the error include some action items for clarity?

[briemla]

The publisher was configured correct. See my answer below for the reason.

[Keshish]

Hi @briemla,
I am also getting the exact same error, but can't understand what is the problem,

name: Manual Tag Release

on:
  push:
    tags:
      - "[0-9]+.[0-9]+.[0-9]+"
      - "[0-9]+.[0-9]+.[0-9]+.post[0-9]+"
      - "[0-9]+.[0-9]+.[0-9]+[a-b][0-9]+"
      - "[0-9]+.[0-9]+.[0-9]+rc[0-9]+"

jobs:
  build:
    name: Build the source tarball and the wheel
    runs-on: ubuntu-latest
    environment: release
    steps:
      - name: Check out repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: "3.11"

      - name: Install build tool
        run: |
          pip install --upgrade pip
          pip install build

      - name: Build the packages
        run: python -m build

      - name: Archive packages
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist

  publish:
    runs-on: ubuntu-latest
    needs: [build] 
    permissions:
      id-token: write
    steps:
      - name: Download packages
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist

      - name: Publish to Test PyPI (Trusted Publishing)
        if: contains(github.ref_name, 'rc')
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          repository-url: "https://test.pypi.org/legacy/"

  release:
    runs-on: ubuntu-latest
    needs: [build]
    permissions:
      contents: write   # needed to create releases
    steps:
      - name: Check out repository
        uses: actions/checkout@v3

      - name: Create GitHub Release
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ github.ref_name }}
          name: ${{ github.ref_name }}
          prerelease: ${{ contains(github.ref_name, 'rc') }}

Thank you in advance!

[webknjaz]

You misconfigured something. Also, I recommend applying environment to the publishing job.

[briemla]

The error lies in the usage of env.PYPI_REPO_URL as an attribute to the action. This variable is defined in the vars-Context. Changing it to vars.PYPI_REPO_URL fixed the issue.

[webknjaz]

Oh wow, I didn't notice it not being defined… I had to resort to remapping ${{ env }} things through job outputs in a number of occasions in the past, namely when reusable workflows were in play.

I don't really like the ${{ vars }} context since it's configured in a detached location (the repo/org settings) and might end up breaking if somebody touches that, which would be rather difficult to troubleshoot...

[webknjaz]

I wonder if we can have a sanity check for this… Your job run has repository_url: https://upload.pypi.org/legacy/ in the log, which is our default. And GitHub Actions is built to choose defaults if an empty string is passed. I don't think we can detect this programmatically, but maybe printing out a big warning “You're attempting to upload to ” on errors would make improve the experience…

cc @woodruffw

[webknjaz]

@briemla I've taken another look at your workflows and posted an issue with other problems you've got over there: OpenTrafficCam/OTAnalytics#633.

[woodruffw]

Yeah, I think this is hard to detect programmatically, although being noisy about which index is being contacted seems like a decent halfway point (so that the maintainer can at least see that it's obviously wrong).