Today I learned that the
GITHUB_ACTOR on a re-opened pull request reflects the person re-opening it, not the original creator.
We have a GitHub Actions workflow Disallowed content checker that ensures that contributions coming in via PRs are targeting the appropriate content. The workflow was duly triggered, as expected, and appropriately alerted the user that the contribution was outside of the desired target location.
We want to allow administrators of the repo to be able to maintain content across the whole repo, rather than restrict them, and we want those who are not administrators to be restricted. We do this by checking the collaborator permissions, using the Collaborators section of the GitHub API, like this:
gh api \
--jq .permission \
So far so good.
Shortly after opening the PR, the user closed it (by mistake, I think), and it was re-opened by my colleague and fellow Contribution Guidelines administrator Jens. As a result of this re-opening of the PR, the workflow was triggered again.
However, this time, no disallowed content alert was raised. Why was this?
Looking at the execution for that workflow run, it's clear that the steps that would have caused an alert to be issued were skipped; the skip logic looks like this:
- id: check_files_changed
name: Checks if disallowed content has been changed
if: env.repo_permission != 'admin'
- id: comment_on_disallowed
if: steps.check_files_changed.outputs.disallowed == 'true'
So it would seem that the permissions for the
GITHUB_ACTOR in this subsequent execution were 'admin'. Why?
Because, as it turns out (and I confirmed this with a simple test just now) the value of
GITHUB_ACTOR is set to the user who opens -- or re-opens -- a PR. In this case it was Jens, an administrator.
This is not what I'd expected, so I thought I'd write it up and share it.