scope of restricting workflow on main repo

[nickreich]

I notice that just one of the actions has the option to restrict the workflow to the original hub repo. Is this a more general option that should be included (even if just commented out) in all template actions posted on this repo?

[annakrystalli]

Thanks for the issue!

Currently I've purposely allowed the validate-submission workflow to run on forks as this is something folks who may be using branches and pull requests within their team forks to collaborate on submissions might find useful.

The dependency caching workflow is a scheduled workflow which could use up resources unnecessarily on forks (and perhaps without teams realising) hence I felt it polite for it to be designed to only run on the main hub (where any pull requests from forks can access the cache anyways). I note that, in response to complaints about this very issue, GitHub makes fork owners explicitly accept running scheduled workflows when they first fork a repository now and they are disabled by default.

For me these two settings make sense and I don't especially see a reason to include a commented out option for this in validate-submission as I don't see the purpose of a hub ever forcing forks not to be able to run the workflow on their own branches. On the other hand I consider only running the scheduled caching of dependencies on the main hub repo a must.

There are ways to enable/disable workflows in individual repositories/forks so perhaps we can include signposting to this for teams forking hub repositories and wanting to manage for workflows themselves? e.g. to here: https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow

I also am happy to touch upon this in a meeting, hearing other people's thoughts and perhaps design some more explicit criteria of when a workflow should be designed to:

• work on forks as well
• work only on main repo
• be easily configurable to change from one state to the other

[nickreich]

Your reasoning on this all sounds very solid to me, and the existing functionality seems good. I do think it might make sense to develop the kind of criteria that you outline here. Also agree that hearing others' thoughts would be useful.