Only consider scheduled postsubmit runs

[drigz]

Without this parameter, the API will also return commits from PRs, which may not have been reviewed and could be malicious.

This has the downside that if you're trying to fix the release workflow you need to change the schedules or be limited to one attempted fix per day, but the alternatives (see below) are also not ideal.

For defense in depth, we also check against the head_repository id, which I tested by temporarily changing event=schedule to actor=totoro642, in which case the action fails with:

Unexpected head repository ID: 817231418 - check postsubmit.yml configuration

Alternatives considered:

• Changing postsubmit to run on push and then having the release workflow filter with event=push instead. This would make it easier to manually trigger a release from a recently submitted change, but doesn't address the (more common) issue that the Postsubmit fails due to some unrelated cloud-side breakage, and must be retriggered after intervening on the GKE cluster to get a green run.
• Changing postsubmit to directly trigger the release action on the current commit: This would let us remove the git clone pattern that makes the attack possible, but at the cost of allowing actions to trigger other actions, which feels like it could open another class of attacks (such as triggering a release from older, insecure code).
• Changing release to trigger on tag creation rather than a schedule. This would mean that only people with permissions to create tags can create releases, which is probably more standard on GitHub , but diverges from the "autopush" model we're using so would need discussion with other team members.

http://b/348316770

[drigz]

@mering PTAL - I also updated the description. I decided against git branch --contains because it seemed to duplicate the existing checks - and might be annoying if we start maintaining release branches.

EDIT: Markus told me that there's a "PTAL" button in GitHub! 🎉

[mering]

@mering PTAL - I also updated the description. I decided against git branch --contains because it seemed to duplicate the existing checks - and might be annoying if we start maintaining release branches.

I agree that the branch=main query filter together with head_repository.id check would be at least equivalent to the git branch --contains (probably even superior).