I manage about 15 repositories and want to run mostly similar pull-request and branch workflows across all of them. Ideally, the automation definitions and shared workflow logic would live in a dedicated repository rather than being committed alongside each product's code.
For example, if I add a new input or feature to a shared workflow and want to enable it for 10 repositories, I currently have to update those repositories individually. Because the workflow is evaluated from each repository's branch, those changes may also need to be merged into every open pull request. Another problem occurs when a workflow variable is incorrect on a release branch: fixing the automation requires changing that branch even though the product code itself is unaffected.
Are there CI/CD tools or architectural patterns that let one central repository define rules such as "run on pull request" or "run on the main branch" for many services, while also hosting reusable workflow code? I'm looking for a way to centralize automation without requiring every application repository to carry and update its own workflow configuration.
4 Answers
Azure DevOps YAML pipelines and Argo Workflows are worth evaluating. Both can separate pipeline definitions from application repositories to a greater degree, although the best choice depends on whether you need event-driven CI, deployment orchestration, or both.
A common approach is to keep reusable workflows in a dedicated, access-controlled repository and have each service call them. That gives you one place to maintain the shared implementation and lets an infrastructure team control changes. Most CI platforms have an equivalent concept.
Another option is to package the actual behavior as a versioned action or task in its own repository. The service pipelines reference a released version, and an automated dependency tool opens update changes when a new version is published. Each update is then tested in the consuming repository, which makes breaking changes visible without silently changing every build.
You may also be able to reduce the pain without changing platforms. Automatic rebasing or merge-train support can keep pull requests aligned with the latest workflow version, so shared workflow changes don’t require manually merging the same update into every open branch.
That helps centralize the implementation, but it doesn’t completely remove the update problem. Each repository still needs to reference the workflow and pass its own inputs, and pinned versions or commit references usually have to be updated separately. A versioned action with dependency-update automation can sometimes work better.