v5.0.7 regression: not detecting fork correctly anymore (maybe due to use of workflow_call)

[wdconinc]

As of presumably #1690, v5.0.7, we are noticing that the detection of forked repositories has ceased to function as before.

Before:

• GITHUB_EVENT_PULL_REQUEST_HEAD_LABEL: spack:dependabot/github_actions/codecov/codecov-action-5.0.3
• GITHUB_EVENT_PULL_REQUEST_REPO_FULL_NAME:
• GITHUB_REPOSITORY: spack/spack

After:

• GITHUB_EVENT_PULL_REQUEST_HEAD_LABEL: spack:dependabot/github_actions/codecov/codecov-action-5.0.7
• GITHUB_EVENT_PULL_REQUEST_HEAD_REPO_FULL_NAME: spack/spack
• GITHUB_REPOSITORY: spack/spack

Diff:

  GITHUB_EVENT_PULL_REQUEST_HEAD_LABEL: spack:dependabot/github_actions/codecov/codecov-action-5.0.7
- GITHUB_EVENT_PULL_REQUEST_REPO_FULL_NAME: 
+ GITHUB_EVENT_PULL_REQUEST_HEAD_REPO_FULL_NAME: spack/spack
  GITHUB_REPOSITORY: spack/spack

Since we call this as a workflow_call, the codecov-actions for the fork runs with the upstream GITHUB_REPOSITORY. The test [ "${GITHUB_EVENT_PULL_REQUEST_HEAD_REPO_FULL_NAME}" != "$GITHUB_REPOSITORY" ] fails, where previously [ "${GITHUB_EVENT_PULL_REQUEST_REPO_FULL_NAME}" != "$GITHUB_REPOSITORY" ] used to succeed and result in TOKENLESS getting set.

It appears that the previous behavior may have been unintentional since GITHUB_EVENT_PULL_REQUEST_REPO_FULL_NAME was empty, and #1690 fixed that.

It is possible this is related to #1705, but we do not see any issues with curl calls, and we are using workflow_call which may affect how the event is passed (though the docs indicate that the original pull_request event payload is forwarded).

Ref: spack/spack#47732.

[thomasrockhu-codecov]

@wdconinc yes, that looks like we are pulling the correct env vars now. There was a bug before that was noting almost all PRs as tokenless.

For this PR (and almost all others) spack/spack#47953, since it's not a fork you will need to do one of the following

1. Add the Codecov token to the dependabot secrets (and repository secrets)
2. Change the token requirement settings for the org spack in the org settings in Codecov

[wdconinc]

Thanks a lot! That's beyond my privileges in the spack org, but let me ping the right people.

[thomasrockhu-codecov]

@wdconinc ok! let me know if it works out

[thomasrockhu-codecov]

@wdconinc going to close this out now, let me know if the problem persists

[wdconinc]

Yes, this can be closed. Thanks!

The problem persists, but it seems we were relying on the unintentional behavior before #1690 so codecov itself is not the cause.