Is there a way to make this work with a PR from a fork

[kevinbarabash]

I have the codecov action working for PRs that I create in my repo, but it doesn't work for external contributors. I appears that secrets.CODECOV_TOKEN isn't getting set for external PRs. Is there anyway to get codecov working with PRs from forks?

[tenmozes]

same problem as in #22
if you find the solution please share

[tenmozes]

@ibrahim0814 could you please tell about the future plans and this issue?

[kefranabg]

Regarding security, it would be bad to allows forked PRs to access your GitHub secrets.

[tenmozes]

Ok do we have suitable solution how avoid secret leaking and have tool which works?

[ibrahim0814]

Hi all,

Currently there's no way to make this Action work for forks and PRs from other contributors since secrets are only available to the owner of the repository. We are looking to add tokenless support for Actions once GitHub releases a public API for Actions that would subsequently fix those issues. For context, we call the API during the upload process to verify repository details if no token is provided. However, until an API released, our hands are strapped.

I apologize for the limited capabilities on this particular Action right now, but we're definitely looking for ways to improve it in the near future

Ib

[hugovk]

Please give this a 👍or comment to let GitHub know:

• https://gh.neting.ccmunity/t5/GitHub-Actions/Make-secrets-available-to-builds-of-forks/m-p/30678/highlight/true#M508

[anuraaga]

Hi @ibrahim0814 - found this issue looking into adding a codecov action to a public repo. You mention a dependency on a public Actions API, but I think it should be possible with current APIs. All builds have a temporary access token with read permissions for forks

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token#permissions-for-the-github_token

So it should be possible to forward that to a codecov server and check whether the repository can be accessed by the token using current APIs such as https://developer.github.com/v3/repos/#list-your-repositories. With a repository-specific URL, I don't think it'd even need to parse any response an just check for a 403 on an API URL.

If a user wanted to make sure codecov didn't get a token with write permissions, they can tweak their workflow to use the default GITHUB_TOKEN for pull requests and a custom token scoped to read-only for pushes.

Not the greatest UX, but I think it's better than not working at all :) I'm not sure how the current out-of-box integrations for Travis / Appveyor work but I guess it's a similar process?

[hugovk]

If you hardcode the token, builds on forks (even if no PR is made) will be sent to the pytest's own Codecov, which clutters up the logs somewhat, and fork users cannot see their own coverage before creating PRs.

We temporarily worked around this (python-pillow/Pillow#4266) by adding a "Prepare coverage token" step before the "Upload coverage" step:

    - name: Prepare coverage token
      if: success() && github.repository == 'python-pillow/Pillow'
      run: cp .github/codecov-upstream.yml .codecov.yml

    - name: Upload coverage
      if: success()
      uses: codecov/codecov-action@v1
      with:
        token: ${{ secrets.CODECOV_TOKEN }}
        name: ${{ matrix.os }} Python ${{ matrix.python-version }}

https://github.com/python-pillow/Pillow/blob/ef4a0b2f4c9346db37140f102e80068abc280167/.github/workflows/test.yml#L94-L103

.github/codecov-upstream.yml is the same as .codecov.yml, except it has the hardcoded upstream token for Codecov.

If you do want GHA coverage from your own fork's builds sent to your own fork's Codecov, fetch your token from https://codecov.io/gh/my-username/pytest/settings and add it as CODECOV_TOKEN at https://github.com/my-username/pytest/settings/secrets.

[ishepard]

FYI: https://github.blog/changelog/2020-01-27-github-actions-api-beta/

There finally seems to be an API! And according to this comment, codecov is working on a tokenless upload 😃

[ibrahim0814]

Yes, can confirm. We’re working to release that feature as quickly as possible :)

[smorimoto]

FYI: We can do it this way without doing extra hacks now.
https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

[s-weigand]

@smorimoto thanks for sharing 😄