Not running workflows on "pull_request" events.

[davidlehn]

The workflows here currently only run on "push" events. This works fine when PRs are created for local branches, as it sees the pushes. But when a PR is opened from and external repo, the workflows do not run. This is an issue with outside collaborators making PRs from their clones. We certainly would like to run the tests on such PRs!

Docs:
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#on
https://docs.github.com/en/actions/reference/events-that-trigger-workflows

Current config files use:

  on: [push]

We likely want:

  on: [push, pull_request]

I haven't tested the change yet. Does this seem correct?

As this has been copied all over, it will unfortunately take some time and/or effort to update everything.

Example where workflows were not run:
digitalbazaar/vc-revocation-list#19

[davidlehn]

I did a test, looks like adding pull_request does get workflows to run on PRs from clone branches. Unsure if there are any negative side effects to adding that.

[davidlehn]

Adding pull_request does apparently double up all the checks (at least on initial PR):
digitalbazaar/vc-revocation-list#22
Is there some better solution?

[mattcollier]

On the rare instance where we need to accept PRs from a fork, I have in the past targeted a dev branch in the target repo and accepted the PR there to get CI to run. I believe 3rd parties having any influence over DB's CI minutes is probably not a good idea. If the minutes are free and unlimited, maybe it's nothing to be concerned about.

[kdenhartog]

As far as I remember CI minutes are free and unlimited for OSS, but are charged for private repos. A concern they had with allowing external PRs to trigger workflows is that the PR could be trying to log secrets in the CI pipeline which would allow the adversary opening the PR to discover the secrets kept by the pipeline. For this they just added a way to manually trigger the pipeline for people with appropriate privileges. It would mean the person with the authority would want to do a quick check to make sure nothing is added to perform this attack (e.g. modifications of CI pipeline or adding packages that log ENV variables would be the two most common ways I'd expect that to occur)

See here for more details: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

[aljones15]

+1 to this. We should run on PR.

…

On Thu, Jul 23, 2020 at 7:11 PM Kyle Den Hartog ***@***.***> wrote: As far as I remember CI minutes are free and unlimited for OSS, but are charged for private repos. A concern they had with allowing external PRs to trigger workflows is that the PR could be trying to log secrets in the CI pipeline which would allow the adversary opening the PR to discover the secrets kept by the pipeline. For this they just added a way to manually trigger the pipeline for people with appropriate privileges. See here for more details: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACD6CAP7CL7YMXMC4ECIO3R5C7TFANCNFSM4PGFH62Q> .

-- Andrew Jones

[davidlehn]

@mattcollier I had thought about adding similar workflows to other libs like jsonld.js and forge, where such PRs are not rare. If we figure out the proper config, probably would apply everywhere.

@kdenhartog Yeah, I forget we need to battle evil with complicated workarounds.

I guess there isn't a default button to allow a one-off workflow run for a PR? Maybe can just add that workflow_dispatch without options to get the UI? Will have to experiment.
https://docs.github.com/en/actions/reference/events-that-trigger-workflows#manual-events