oidc: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

[ssbarnea]

A very recent regression appeared for OIDC in the last couple of days and today I faces same error in two repositories that are using the OIDC authentication for uploading the coverage results.

Codecov: Failed to get OIDC token with url: https://codecov.io/. Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

We googled the error and we checked if we have the required permissions as below, but still we seen the failure.

    permissions:
      id-token: write

Considering that https://github.com/codecov/codecov-action/releases/tag/v4.6.0 was release two days ago, I wonder if that regression was not introduce in this release as the upload was working fine before. We use the v4 versioning tag because we assumed that minor version bumps would not introduce breakages.

Examples:

• https://github.com/ansible/event-driven-ansible/actions/runs/11159549800
• https://github.com/ansible/ansible-lint/actions/runs/11163633677/job/31031691286?pr=4353#step:8:15

[ssbarnea]

Apparently v4.6.0 release included a single relevant change well hidden inside the long list of CI/build changes, as #1511 -- and it seems to be related to oidc.

Less important, but I bet others will appreciate if you would tune the changelog generation to at least use sections for the type of changes made or even to hide the non-relevant changes, so they would be easier to read.

[ssbarnea]

@thomasrockhu-codecov can you please look into this? We have the confirmation that this was a regression introduced by v4.6.0. I would personally unpublish it or at least move the v4 tag to point to v4.5.0 which is last known to work.

Minor version changes are not supposed to break integration.

What makes it worse is the if we switch to @v4.5.0 we will see dependabot try to update to @v4.6.0 later and if that is inside a reusable workflow that is in a different repository, we might never know that it will revert the workaround. We would also have to configure dependabot to prevent it from picking this version.

[njzjz]

Another workaround:

      - name: Upload coverage reports to Codecov
        uses: codecov/codecov-action@v4
        with:
          use_oidc: ${{ !(github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork) }}

The error only happens when the id-token write permission is not granted (i.e. in a PR from a forked repository).

[thomasrockhu-codecov]

@ssbarnea I'm so sorry this never showed up in my inbox. I see that the workaround given hopefully works, but I wanted to check up and see if this was still an issue. If so, can you point me to a recent CI run that is broken? Also, is v5 working for this instance?

[mrgrain]

@ssbarnea I'm so sorry this never showed up in my inbox. I see that the workaround given hopefully works, but I wanted to check up and see if this was still an issue. If so, can you point me to a recent CI run that is broken? Also, is v5 working for this instance?

v5 is not working but failing with a seemingly different error:

curl: (3) URL using bad/illegal format or missing URL

https://github.com/cdklabs/cdk-from-cfn/actions/runs/12015198565/job/33492743470?pr=751#step:9:63

Also see #1705

[ssbarnea]

Another workaround:

  - name: Upload coverage reports to Codecov
    uses: codecov/codecov-action@v4
    with:
      use_oidc: ${{ !(github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork) }}

The error only happens when the id-token write permission is not granted (i.e. in a PR from a forked repository).

This is what we had until dependabot updated the action and broke the upload.

Yes, the error does reproduce as the first thing I attempted was to rerun the job.

I should mention that this is using codecov from within a reusable workflow. This means that some environment variables might not be available. Still, https://josh-ops.com/posts/github-actions-oidc-reusable-workflows/ makes me believe it should be.

On the other hand. I seen there something very unstable, adding an url as argument to another url without escaping. Almost for sure this will produce an invalid URL. The code logic needs to be update and maybe make it easier to debug in case of failure.