We are currently using Jenkins, and we make use of their Shared Libraries feature where (part of) the pipeline specification lives in a separate private Git repository. This way you do not have to duplicate CI/CD pipelines among a lot of similar projects which have the same build process, and makes it easy to manage these pipelines in a central location. Especially when you have many projects this is a killer feature.
We are investigating Actions as a possible alternative to a self-hosted Jenkins server, so I am wondering how I would set up such a centralized workflow here… but I have not found anything useful yet. Is this currently possible with Actions? It looks like you can share individual actions among workflows by putting them in a separate public repository, but not the workflows themselves. Keeping the actions themselves private would force you to duplicate them as well, as they then have to live in the same repository as well.
This is the only thing that really keeping us from switching, because otherwise it looks like this will save us a lot of trouble maintaining our own CI server.Â
We have a quite similar requirement. Several repositories use the same workflow structure. Is there any recommendation regarding how to avoid redundancies by having to maintain the same YAML file(s) multiple times? Thanks for your suggestions.
Thank you for being here! As I know there isn’t a provision to accomplish this as of now, we do understand this optimization makes sense and there is an open feedback issue for the team to review, to which I’ve added your input.Â
I also have the same need.
There are multiple repositories, between 10-100 or more that could use the same build steps.
In addition of being DRY, being able to change the build steps of those 100 repositories at once is a powerful tool when managing the CI of modular applications where each module is in a separate repository. The modules could even be developed by another party and the module should be tested with latest code of our repository run by our CI script when changes are done in the other party’s repository.
It seems that it could be possible to use the method provided here as a workaround: Trigger a workflow from another workflow
In this method the many repositories can trigger a workflow in another repository, potentially with some parameters.
The downside is that every tested repository needs to have (write?) access to the repository that executes the CI. I am unsure if its possible to report back the success or failure to the initiator of the CI test.
Second workaround that I have used previously for unifying CI of multiple branches has been to make a single script that spawns a job every day or every week for every repository that is defined. The script then runs the same steps - with given parameters. The CI script could even run a setup script from each branch, which can be unique to that branch.
The downside is that every tested repository needs to be added to this CI script and that the tests cannot use events, such as pull request, push and so.
Third workaround is to make all steps into bash scripts that are hosted in another repository. These bash scripts are then cloned and run. The same can be done with an action.
The downside is that we cannot configure the entire workflow, only some steps of it.
Fourth workaround is to just push new workflows with automation, such as https://github.com/marketplace/actions/deploy-github-actions
The downside is that pushing requires access to the repository and listing of the repositories to push to.
However, I’m not looking forward to paying more than 5 times I do now (Team subscription) for this feature, please tell me you won’t limit this to Enterprise
I’m part of an open-source project maintainers team and we currently rely on Travis Shareable configuration pattern to segment our CI configurations. We consider migrating from Travis to GH Actions. We have 70+ repositories. Many repositories reuse the same CI configuration and other with slight differences. This feature allows us to segment the different reusable parts and assemble them in each repository how we see fit.
It would be awesome to have the same feature with the GH Workflows.
Instructions here: Reusing workflows - GitHub Docs (note that there’s still a line that claims that this isn’t possible, but it is. I think they just missed it when updating the doc)
I just got it working in our enterprise. A couple of things that tripped me up were:
In the “remote” repo, the workflows must still be placed in a .gitthub/workflows folder even if said repo doesn’t actually run builds of itself.
You must enable this the ability for other repos to call workflows in your “remote” repo’s settings:
