Skip to content

Make CI (Github Actions) useful for external contributors (fork) #404

Open
@Martinsos

Description

@Martinsos

So if contributor is new, Github will ask for permissions to run the workflow at all, for their PR. Once that is granted by us, it will run it, but still, it won't supply the secrets if PR came from a fork (not a collaborator). This is a safety measure, and it makes sense, but it also means that our CI fails for all external PRs and doesn't help us understand if code is passing tests or not, meaning we have to check it manually.

Why is this safety measure needed and why does GA do it?
That is because there are a ton of ways for them to steal those secrets or make a mess: from script injection via stuff like PR name or branch name (that we might be using in our GA workflow), to them putting malicious code in the github workflow yaml file, or in the source code in the repo itself (e.g. open saas code).
So to be sure they won't hurt us somehow, we should check their PR thorouhgly, and then there are some ways to force it to run, but it is not super normal (e.g. we can modify GIthub Action so that it allows running actoin from the external fork if it was rerun by one of us). Here is an article about how to do that: https://michaelheap.com/access-secrets-from-forks/ .

Some possible approaches:

  1. Allow Action from external PR to run if it was re-run by one of us (collaborators). This gives us an opportunity to check that PR is not malicious. This can still be dangerous if they sneaked something malicious in the PR, but that is always the danger we have to watch out for, regardless of GA or not, so I don't see it as particularly problematic. Here is an article about how to do that: https://michaelheap.com/access-secrets-from-forks/ .
  2. Modify action so that it runs different job/logic for the external contributors. It would not use secrets and instead do as much of the checking as it can without the secrets. I wonder though how effective that can really be -> we will at the end still probably have to run it locally, to run the full e2e tests. At least it would give some early assurance though.

Potentially we could even do both.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions