don't run scheduled tests in forks

[mathause]

Scheduled workflows also run on forks (e.g. https://github.com/mathause/ESMValCore/actions) - they should be restricted to the main repository on https://github.com/ESMValGroup/ESMValCore. To achieve this see e.g. pydata/xarray#5267 where such a change was implemented.

Not a bug but in lack of a better category I post it here.

[valeriupredoi]

hi @mathause - this is an excellent point! Cheers 🍻 Here are my takes on it:

• the xarray implementation is terrible: it's a recipe for disaster in many ways, one of them being Github API changing, another being an eventual package name change etc
• for users that don't want Actions to run in their forks, they can simply turn them off with three clicks, see https://github.com/orgs/community/discussions/26704
• for us, it doesn't matter - the Actions that run in the fork are the fork owner's Actions - if they don't want those, they can turn them off as explained above, but I'd keep them, personally (matter of taste/option); NOTE that those Actions do not interfere with the main repo's Actions (due to GitHub Secrets and security)
• we could, in principle, limit any Action change by restricting permissions, as explained here https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository

[mathause]

hi @mathause - this is an excellent point! Cheers 🍻 Here are my takes on it:

• the xarray implementation is terrible: it's a recipe for disaster in many ways, one of them being Github API changing, another being an eventual package name change etc

Yes using the github API is certainly a terrible idea! Because you can totally not use the github API when interacting with github actions! And name changes of repos happen all the time. So sorry for suggesting to use github API! How stupid of me.

• for users that don't want Actions to run in their forks, they can simply turn them off with three clicks, see https://github.com/orgs/community/discussions/26704

I didn't know that and consider myself an experience github user. But yes that's a viable option - so fair enough. You do push the action to the user, which I find unnecessary and most people also don't unsubscribe from emails they never read but 🤷‍♂️

• for us, it doesn't matter - the Actions that run in the fork are the fork owner's Actions - if they don't want those, they can turn them off as explained above, but I'd keep them, personally (matter of taste/option); NOTE that those Actions do not interfere with the main repo's Actions (due to GitHub Secrets and security)

• we could, in principle, limit any Action change by restricting permissions, as explained here https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository

I don't see how running actions on your personal fork provide any value - in contrast to the ones on the main repo but that can be up to personal taste of course. So obviously fine with me if you want to keep it as is.

[valeriupredoi]

I don't see how running actions on your personal fork provide any value - in contrast to the ones on the main repo but that can be up to personal taste of course. So obviously fine with me if you want to keep it as is.

I like freebies 😁 No, but scheduled/cron actions on a fork are not useful to me either, unless the fork is so different than the upstream, that it becomes a separate repo on its own, needing scheduled actions for CI 🍺

[bouweandela]

It would be nice to consider our carbon footprint too. Avoiding running useless jobs in CI is a really easy way to do something about that. As far as I can see, we only use GitHub actions for things that do not need to be run on forks, so I agree that if there is some way for us to turn them off, we should do it.

As an additional measure, we could also consider only running the actions with the lowest and highest supported version of Python, instead of the full range. I've never seen a case where testing the middle versions provided new insights.

[bouweandela]

I looked into this in a bit more detail, and according to the GitHub documentation here:

When a public repository is forked, scheduled workflows are disabled by default.

So these runs appear to be either a bug in GitHub or caused by users enabling them manually.

[valeriupredoi]

thank you @bouweandela - I meant to post exactly this myself when you pinged me about this a few days ago, but then I did what I usually do in such cases - got distracted with another shiny problem to look into 😁 EDIT (I did it again!): it's 99.9% not a GH bug since we have quite a few forks and GAs they're not running in those forks - unless it's a very infrequent bug, that is