Open mnbf9rca opened 1 year ago
Hey @mnbf9rca! Unfortunately this is actually a security feature of dependabot's integration in GitHub. PRs that are triggered by dependabot (either push
or pull_request
) are assumed to run in a non-secure environment and therefore do not have access to secrets. So jest-report-action
actually receives and empty string in access-token: ${{ secrets.GITHUB_TOKEN }}
and therefore the request to create the PR annotations fails.
Here's the link to the official information regarding this change: https://github.com/dependabot/dependabot-core/issues/3253#issuecomment-797125425
As to a solution, yes python-coverage-comment is using is the correct workaround for this issue. Since jest-report-action
only expects the report file you can use another action to upload the junit.xml
to an artifact and then have the next workflow pick it up/downloading it and running jest-report-action
with that junit.xml
file as input.
You can use https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#sharing-data-between-workflow-runs as inspiration for how to make the artifact upload/download work.
Take a look at the dependabot link for tips on how to trigger the second workflow run so that it has access to the secrets.
When a PR is raised by Dependabot (or anyone without write access to a repo), although all the tests pass, the action is unable to annotate the PR, instead throwing an error e.g. and the workflow fails:
I believe this will happen whenever someone raises a PR against a repo that they don't have write access to.
Another action which i use for Python coverage reporting (python-coverage-comment) solves this by publishing the coverage report as an artefact when the tests are executed, and then fetching it in a separate workflow to report. Is that possible with this action?
here's the broken JS workflow: