It doesn’t matter how smart you are with reusable workflows you will never get to a truly DRY setup that scales for dozens of repositories.
Another major pain is that we still haven’t private actions. It was due end of 2021 (maybe it is out now but I checked a couple of days ago).
Setting up runners to look after a pool of repositories needs elevated permissions.
GH offers a way to enforce a list of enabled actions but this does not work with private binary registries hosting pre built Docker actions. The only thing that could prevent you to pull software at runtime from the internet, which means, if you want to have a decent security posture all you are left with is referencing actions using the full git sha version.
Many common use case require hacks, which is fun for a weekend project but isn’t great for a large scale operation. An example is simply running a workflow dynamically targeting the folders containing changes. At the moment you have to create a job, generate a build matrix on the fly and pass it in input as the matrix to the actual job.
> Another major pain is that we still haven’t private actions. It was due end of 2021 (maybe it is out now but I checked a couple of days ago).
I'm looking forward to this landing too. In the meantime, though, checking out the repository that contains the Actions and referencing a local path works fine so this hasn't really been a blocker for us.
Edit: per sibling comment, it seems that this feature became available in the last few days. Nice!
The only way I'm aware of to use a private action is to clone the repository it's in using a personal access token, and then use a local relative path to the action to run it.
