CI jobs fail on forked repositories

[hibariya]

According to Github's document, workflows triggered by forked repositories are not able to fetch secrets of their upstream repository for security reasons.

https://docs.github.com/en/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow

For that reason, the following have failed.

• https://github.com/stripe-samples/subscription-use-cases/runs/1698504333
• https://github.com/stripe-samples/checkout-single-subscription/runs/1698500843
• https://github.com/stripe-samples/checkout-one-time-payments/runs/1698498734

As long as the CI requires secrets, workflows should not be triggered on forked repositories.

[hibariya]

I came up with 3 options for this. The main motivation to disable CI on forked repositories is to avoid making contributors confuse. For that reason, 2 is the most reasonable of them for me.

1. Skip each job on forked repositories and make the run successful.

Like this: hibariya/checkout-single-subscription@2a65fbf
This indicates the job was "successful" and it looks misleading.

2. Run only push events to master branches and decrease CI runs on forked repositories.

Like this: hibariya/checkout-single-subscription@9e61427
Easy to maintain. However, it cannot eliminate all unintended CI runs. When some commits are pushed into the master on a forked repository, it will trigger CI.

3. Cancel CI jobs when the repository is forked one

Like this: https://github.jparrowsec.cnmunity/t/is-there-a-way-to-cancel-a-running-workflow-within-one-of-its-jobs/17493/4
This will trigger notifications like "Run cancelled". Looks misleading as well as 1.

[cjavilla-stripe]

I think number 2 is okay for now. And I think if someone is pushing to master on their forked repo that it might be valuable?

[cjavilla-stripe]

For option 2, would CI fail when they push to their own repo?

[hibariya]

It would fail if they push to master on their own repo. When they push to other branches, CI would not run.