News for hackers. Stuff that matters.
Re:GitHub Actions is experiencing degraded performance by qqii on Monday March 01, 2021 @02:16PM (#26306914)
The maintainer would reject such a PR? Even if the CI run takes from the HEAD it would still be the responsibility for the repo owner to not allow the PR to be run in the first place.
Re:GitHub Actions is experiencing degraded performance by growse on Monday March 01, 2021 @03:45PM (#26308149)
But the trigger for the run in defined in the workflow file.

So even if you have a workflow that requires a manual trigger, I can just fork, and create a PR that updates that trigger to be `pull_request` and the workflow will run as soon as I create the PR. I don't need the PR to be accepted before I can start running arbitrary code on your self-hosted runner.

Or am I missing something?

Re:GitHub Actions is experiencing degraded performance by qqii on Friday March 05, 2021 @10:02AM (#26357540)
Perhaps I did not explain clearly, your PR does not automatically run the workflow.

Perhaps it would be more clear to imagine two files, a workflow file describing the CI steps and a permission file describing what can trigger the CI.

The CI will use the permission file from the last trusted commit (which would also be the last commit that the CI was run on) but uses the workflow file of the current commit.

In your case you create a PR that updates both the workflow and permissions file. The CI sees that the previous trusted commit requires that I, the repo owner has to manually submit unknown PRs to the CI. Seeing that your PR is malicious, I don't submit the PR to the CI.

Now that I've layed it out explicitly I realise that the non intuitiveness comes from using git to track CI configuration in the same repo.