Closed gerryfletch closed 3 years ago
[…] All are created in the same way (they're dependabot updates).
I assume this flaky behaviour started on March 1st? On that date, GitHub changed the permissions of the token issued to workflow runs started by GitHub Actions: Announcement blog post.
Since then, workflow runs which are started by Dependabot can't write to the repo. As stated in the blog post, you could use the pull_request_target
-event to listen to in your workflow. We've covered this in the README, but I would not encourage to use it: It has it's own security risks and runs are not shown in the pull request status list.
You could solve this problem by writing another workflow that runs, when a Dependabot PR is merged to your default branch (You would somehow have to detect if the commit/PR was made by Dependabot). Or you could try using a personal access token to checkout the repository in your existing workflow (docs).
Thanks for the response. Perhaps I misunderstood the details in the announcement blog post. This repository is not a fork, but I did come across those problems with dependabot merging the PR itself. Curious that this only happens some of the time.
I'll have a go at configuring a separate token. Thanks.
Version of the Action
v4.11.0
Describe the bug Occasionally the action will fail with an internal status code of
128
, reporting403
Forbidden:(Omitted the repo and org)
This happens when git does not exit cleanly, but since it works 50% of the time I'm not sure that it's to do with my configuration.
To Reproduce This behaviour is flaky. I would say roughly 50% of my builds fail with this. All are created in the same way (they're dependabot updates). Rerunning the build usually fixes it, but this is costing me significant minutes in GHA.
Expected behavior 100% success rate.
Used Workflow