CI blocks after a commit is pushed by github workflow

[pysel]

Select Topic Area

Question

Body

I have a workflow that is updating the dependencies of a go project, when a push to a local branch happens, and pushes these changes to the same branch. However, if it happens that these automatic pushes are made to the branch with an opened PR, the CI blocks in the PR with Expected — Waiting for status to be reported. It can be solved by manual closing/reopening a PR, but that is a not desirable overhead for developers.

I was wondering if anyone knows the reason for that. This is the workflow that is pushing some changes with updated dependencies to the local branch, and this:

is how CI looks after an auto-commit is made

[airtower-luna]

The problem is that the push is done using the GITHUB_TOKEN, which won't create new workflow runs, so the required checks never happen for the automatically created commit. If you want the push to create new workflow runs, you need to use a PAT instead to authorized the push (generally the best way to do it is to pass it to actions/checkout using its token parameter).

[pysel]

for example, in the link you shared above, there is a github token permissions topic, which covers several scopes and corresponding accesses. Another way to put my question, I guess, is: which scope is responsible for CI blocking/not blocking after a workflow push?

[airtower-luna]

It's not a scope, it's a special case for the GITHUB_TOKEN by design. To quote the documentation I linked above:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

[pysel]

thanks for the response @airtower-luna! The reason I asked this question is more about understanding what specific permission (lets call it like that) a token has to have in order not to block CI. I am working on this workflow for a repository that has a few secrets, however, when using them in the workflow, the CI still blocks.

So, I will try to rephrase my question: what specific permissions does the PAT grants that the CI is not blocking when you use it? Does it basically mean that using PAT is pretty much equal to authenticating as a user, on behalf of who the commit is pushed, which is the requirement for the CI not to block? If so, is there a way to commit on behalf of a github action bot without blocking a CI? Let me know if that makes sense, please, thank you

[airtower-luna]

Does it basically mean that using PAT is pretty much equal to authenticating as a user, on behalf of who the commit is pushed, which is the requirement for the CI not to block?

Pretty much, yes. Except there's nothing blocking as such, the GITHUB_TOKEN just can't trigger workflow runs for the newly pushed commit. Which then implicitly blocks the merge if you have a branch protection rule that requires those runs.

If so, is there a way to commit on behalf of a github action bot without blocking a CI?

If you mean pushing without a PAT, no. If you mean having the actions bot show as the commit author, that should work if you set author name and email as shown in the actions/checkout docs.

[pysel]

thanks!