3 ms·

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

• growse 6y ago
  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?
  • qqii 6y ago
    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.