Backport workflow: Use access token to run CI on PRs?

[The-Compiler]

Regarding CI not running, right - CI doesn't run when triggered this way - this also happens for the create-pull-request actions and similar. Workaround is to close & reopen, then it triggers. It's also possible to use a user token (pytestbot), but that has its own security considerations.

Originally posted by @bluetech in #9430 (comment)

[webknjaz]

It's also possible to use a user token (pytestbot), but that has its own security considerations.

Instead of using a PAT, I'd recommend making a GitHub App and provisioning its credentials to the workflow via https://github.com/marketplace/actions/github-app-token + use environments feature in workflows so that the secrets are not global.

Another hack I've been using is adding a deployment key to the repo + adding its private key as a secret. Then, in the workflows, add ssh-key to actions/checkout@v2 with that. Then, any subsequent Git interactions in the job will be configured to use that SSH key, enabling the push event propagation (for triggering CI / notifying other listeners).

[The-Compiler]

FWIW this seems like a good overview of possibilities (some of which @webknjaz has already mentioned): https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#workarounds-to-trigger-further-workflow-runs

[webknjaz]

Hey @The-Compiler, have I offered you to use my Patchback GitHub App? I don't remember if I did, but it so happened that a number of projects are using it successfully (some of which I didn't even know existed).
So if you're up to trying it out, it's here https://github.com/apps/patchback. Here's an example config https://github.com/ansible-collections/community.general/blob/main/.github/patchback.yml but it'll work just fine even without one. Example PR: aio-libs/aiohttp#6749 (comment).

[bluetech]

Another hack I've been using is adding a deployment key to the repo + adding its private key as a secret. Then, in the workflows, add ssh-key to actions/checkout@v2 with that. Then, any subsequent Git interactions in the job will be configured to use that SSH key, enabling the push event propagation (for triggering CI / notifying other listeners).

I can easily do this one -- I will generate the key pair, add the private key as a secret and throw it away. Any other core dev wants to ack this (or add a key directly given my ack)?

[nicoddemus]

@bluetech please go ahead! Thanks!

[bluetech]

I realized after the fact what @webknjaz and the peter-evans/create-pr docs say, that a deploy key will only trigger push event but not pull-request event which is what we need. So I created a PR to use @pytestbot key instead (secret already configured).

[webknjaz]

I realized after the fact what @webknjaz and the peter-evans/create-pr docs say, that a deploy key will only trigger push event but not pull-request event which is what we need.

That's not really accurate. If there is a PR for the given branch, the pull_request event will happen too (and will be processed unless GHA workflow is set up to ignore the branch name pattern, for example). This has nothing to do with the deployment key. The problems with non-propagating events are only there if you use ${{ secrets.GITHUB_TOKEN }}. Any other tokens will cause normal events to happen.

[webknjaz]

@bluetech I looked at your PR #10346, and now I see why you've drawn this connection. This is because both PR creation and pushing to Git used the same token. I've done one clever thing in one of my projects — the workflow first pushes an empty commit (push to a new branch happens), then a PR is created using a normal ${{ secrets.GITHUB_TOKEN }} (because there's a branch that exists, it's possible — but this doesn't cause any PR-related events); then, the proper commits are force-pushed to that branch using a deployment key. And this time, both push and pull_request events happen because ${{ secrets.GITHUB_TOKEN }} is not in use. And so this allows the CI to be triggered.

[bluetech]

Reopening, see #10354...

[bluetech]

@webknjaz Heh that's indeed clever. We can try this if nothing else works. Slight downside is that it will create extra notifications for the last push, but that's not too bad.