Search code examples
githubgithub-actions

Centralizing repo actions in GitHub organization


We are currently having one organization in which all the repositories are copies of a template repository.

This has certain initial folder/file structure plus some git actions which basically read the repositories that called them and commits/pushes certain stuff.

All actions are running under a single self-hosted runner and no need to split that load (for now...).

Current Setup

The main problem I am having here is how to distribute all the actions changes done in the template among all the other different repositories (we are talking about close to 800 small size repos).

So was thinking to change the approach in a way that all executions are done in the template repository by doing the commits (via API?) to the "real" repository. No environments being used, only organization secrets and variables.

enter image description here

This way any change in the template repository would be directly available for the other ones.

I was also thinking adding a new action in the template repository that would push any changes to all the repositories massively but sounds for me like too much...

Is that a proper setup? A better approach to be able to distribute or to make those changes available to everyone in a relatively easy way?

EDIT: A basic example would be one action that reads the headers or all files in the repository and generates a summary of the content in a summary.txt file under the same repository.

This way that summary.txt file would be always up to date.

With the template repository I assure that new repos will get the latest yaml version. But the existing ones won't get any further changes done in the actions yaml.

So basically that is the main struggle I have due to the big number of repositories.

With the second approach there would be a single yaml with the full codeset and the different repositories would basically call the actions in the template repo (with the latest changes already on them)


Solution

  • Don't copy the workflow files. Instead, make them into reusable workflows. That way the bulk of the logic remains in the shared, reusable workflow.

    The template repository contains workflow files which call the reusable workflows. Only these are copied to the other repositories.

    Ideally, the reusable workflows take no arguments and instead get all their information from contexts. This avoids having to update every repository because you want to pass in a new argument to a shared workflow.