Some GitHub Actions will always fail for external PRs.

[Jonas-Sander]

When a PR is opened by an external contributor the actions web-preview and ios-integration-test will always fail since they can't access secrets.
Example PR: #347

As described in this article Actions that have the trigger pull_request can't access secrets, if they are triggered on a PR from an external contributor (no write permissions for the repo), so that these secrets can't be easily stolen.

Because we use these secrets for the following tasks, these tasks will fail if the secrets are not available

1. Deploy the app (web-preview action)
   Secret: FIREBASE_HOSTING_PROD_KEY
2. Run integration tests with credentials for accounts (ios-integration-test, android-integration-test)
   Secrets: INTEGRATION_TEST_USER_1_EMAIL, INTEGRATION_TEST_USER_1_PASSWORD
3. Build MacOS app (macos-build-test)
   https://github.com/SharezoneApp/sharezone-app/actions/runs/4583590526/jobs/8094642454

Potential Solutions

web-preview action

Split the workflow into building the code for web via a pull_request trigger, upload the artifact and run a second action on success via the workflow_run trigger, which will upload the builded code to Firebase Hosting. This would seperate building the untrusted code (dangerous) and uploading the code that was just build (not dangerous - hopefully 😉).
The second Action will have access to the secrets, since it is triggered on workflow_run, not pull_request.
This approach is described in more details with examples here.

ios-integration-test, android-integration-test action

Since we can't split the workflow into several parts like above we need another approach.

Instead of manually creating account credentials for the tests to use, we could automate creating new Sharezone accounts via the test code. This would not only include creating a Firebase Auth account, but also adding the necessary setup data into the user document (e.g. type of user - student, teacher, parent).

[nilsreichardt]

PRs by Dependabot also treated as fork PR (see this blog article) so we have there the same problem.

[nilsreichardt]

I think the easiest solution for the beginning would be have something like a "safe to build" label which triggers the CI for fork PRs, right? Because I think generating the E2E account is nothing we will do the in the next months.

[Jonas-Sander]

Would be fine with me, although it should be ensured that it automatically gets removed if a new commit is pushed (as this could be malicious again)

[nilsreichardt]

Here is my idea / structure:

graph TD
A{Is PR a fork?}
A -- Yes --> B[Remove the 'safe to build' label]
A -- No  --> C[Execute the 'changes' workflow]
B --> C
C --> D{Is PR a fork?}
D -- Yes --> E{Has 'safe to build' label?}
D -- No  --> H[Execute the workflows]
E -- Yes --> H
E -- No  --> F[Cancel]

Loading