Who will be the GitHub actor when a workflow runs on a schedule?

[localheinz]

The documentation at https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#github-context states that github.actor resolves to The login of the user that initiated the workflow run.

Now, who would that be when the workflow runs on a schedule?

I noticed in https://github.com/ergebnis/composer-normalize/runs/388922221 (a scheduled run) that the actor resolves to localheinz (that’s me).

[weide-zhou]

The latest user who create the schedule trigger will be the actor for the schedule workflow.

As mentioned, you can export ‘github.actor’ in context for check.

For instance, if user A create the schedule trigger, workflow is triggered with actor ‘user A’, then user B modified the schedule setting, workflow is triggered with actor ‘user B’.

scheduleactor.png765×818 37.3 KB

[henninge]

So "git blame" for our workflow currently reads

aaaaaaaaa (User A 2022-01-13 20:22:28 +0100  21)   schedule:
bbbbbbbbb (User B 2022-05-04 17:36:23 +0200  22)     - cron: "45 */4 * * *"

and User A shows up as the actor in the UI, like this:

Triggered via schedule 3 hours ago
User A  bbbbbbbbb

Or is the user in the UI not the actor? It seems that whoever added the schedule: in the first place gets listed.

[sxlijin]

Just ran a bunch of tests of this. The user in the blame is not guaranteed to be the same as the actor; it just usually happens to be the same by coincidence.

The real answer is this: the identity of the actor is the identity used for the push operation that last updated the workflow.

In other words, it has absolutely nothing to do with the author or committer of the latest commit to update the workflow. This makes sense, in a confusing way: from GH's perspective, when a workflow is updated, the only actual "identity" it has is the authenticated identity backing the authorization claim on the push operation.

In fact, GitHub fundamentally cannot use the author or committer to infer a principal (identity), because commits generally contain no proof about the identity of the author or committer (signed commits being the exception. technically, but even then, you can't use a signed commit to resolve a principal; you use the public key associated with a principal to verify the signature). When the GitHub UI links to an account claiming "USER committed on Oct 3" or lists USER in the blame for a file, what GitHub is really doing is making a best-effort association from the author.email of the commit in question to a GitHub user. This is a purely best-effort operation with no authn/z implications. which is why GitHub Security explicitly considers email address impersonation to be a non-issue.

By contrast, workflows are - I assume - entities that exist somewhere in a GitHub database which can only be updated by authorized operations. Using the principal of the authorization claim on the most recent update as the actor for a scheduled workflow is pretty logical to me, if non-obvious.

Here's a test I ran of this, where the commit that updated the workflow file was created with the email address of sxlijin1:

[bparthas21]

I think this answer is wrong. In my experience, it has nothing to do with who edited the cron schedule. All it matters is who edited the file last immaterial of what line was changed in the workflow file. @localheinz @weide-zhou

[dhalbert]

I asked GitHub support about this and got the following answer:

Indirectly mentioned in this documentation snippet, the actor tied to a workflow run triggered on schedule is the user who last edited the cron syntax on the workflow file, or re-enabled the workflow after it has been disabled.

Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.

In this case, you can have the @[desired new user] disable and re-enable the workflow so that they become the actor for further workflow runs.

I had first tried to change the actor by merging a PR by the desired new user to the cron job .yml action. That did not change the actor. What did work was to log in as the new user and then disable and re-enable the workflow, as linked to above.

[bejgli]

This is very inconvenient when it comes to sending workflow run notifications to a specific user. Are there any plans for an explicit "actor" option for scheduled workflows?

[younsl]

I think so. It’s uncomfortable because it’s not intuitive.