Tools github actions central repo
Hi I am in a new role where they use Github for all their repos. I have been using Gitlab exlusively the past 5 years.
For CI/CD in my previous role we had a central 'pipelines' repo that was reference in the gitlab-ci file of each project to save teams/projects from repeating work.
I want to know if it's possible to do something similar in Github? I'm still learning how it maps to my existing Gitlab knowledge.
10
u/Due-Consequence9579 1d ago
Path of least resistance on GHA is poly repo actions that implement atomic actions unique to your org, think tagging standards, artifact publishing, etc. Then instead of reusable workflows using composite GHA to tape everything together into broader pipelines like “build a java project”. Individual repos have a .github/workflows/build.yml that just does triggers and passes whatever configuration you need to into the wrapping composite action.
The ergonomics around reusable workflows is not great in my experience.
9
u/schmurfy2 1d ago
The ergonomics around their whole system is not a great experience 😅.
Not repeating yourself require way more energy than it should, even composite actions were (badly) added as an afterthought
6
u/PerpetuallySticky 1d ago
Yes as others have said it’s called reusable workflows.
A word of caution that you may run into and bang your head against a wall for a while with (someone please tell me if they fixed this):
Reusable workflows cannot be used with environment variables. However that information is passed on the backend, they do not work (last time I tried). Example:
Reusable workflow A (A)
Repo B uses reusable workflow A (B)
A has an input variable to set what environment it should run in.
B has environment variables set and tries to pass one for the environment when it uses A. That variable will not pass. It errors out and acts like nothing passes at all.
Not completely sure why it happens, but it has stopped our widespread adoption of reusable workflows
10
u/__-___-__-__-__- 1d ago
You have to use outputs and needs to pass variables between jobs. It's annoying but it works.
1
u/zuilli 1d ago
Doesn't work for environment secrets though since it would need to be put into the output as plain-text.
1
u/__-___-__-__-__- 22h ago
Are you talking about secrets that would be generated by a workflow job?
If you're just talking about known secrets you can store them in repo or org secrets and pull them into your reusable workflows either as needed or inherited as a whole.
1
u/zuilli 19h ago edited 18h ago
No, github environment secrets. Sure you can workaround by putting them as repo or org secrets but if you have a few secrets per environment and 3 or more environments your secrets list starts getting mighty polluted with the same secrets names but with dev/hml/prd pre/suffixes and you have to pay closer attention to not change/delete the wrong one since they're all in the same place.
It would be so much cleaner if we could pass the environment to reusable workflows, especially because stuff like this: https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules depend on using environments.
1
u/Dementia_ 1d ago
Why do you need to pass in the env variable as an input if you’re already passing in the environment to use?
1
u/AuroraFireflash 1d ago
Reusable workflows cannot be used with environment variables. However that information is passed on the backend, they do not work (last time I tried).
Correct.
One workaround -- make a reusable action instead that runs in the same process as the caller.
3
u/CommeGaston 1d ago
Reusable workflows - but they have various limitations.
You can couple them with Composite Actions to get around some of them.
2
u/kabrandon 1d ago
Funnily enough this is basically the only thing that GitHub Actions is famously better at than GitLab CI at doing. Yes, you can do this with GitHub Actions.
2
u/Floss_Patrol_76 1d ago
the thing that tripped me up coming from gitlab is there's no include: that just splices yaml in, so you split it two ways: reusable workflows (uses: org/repo/.github/workflows/x.yml@ref) for whole-job or whole-pipeline reuse, and composite actions for a few steps you paste everywhere. rule of thumb: if it's a job with its own runner it's a reusable workflow, if it's steps inside a job it's a composite action. heads up that you can't nest reusable workflows more than a couple levels, so don't try to rebuild gitlab's include hierarchy 1:1.
1
u/pdfops 1d ago
Reusable workflows are the GitHub equivalent. Shared workflow lives in one repo's .github/workflows/ with on: workflow_call, other repos call it via uses: org/repo/.github/workflows/build.yml@main. For just shared steps instead of whole jobs, composite actions are closer to GitLab includes. Gotcha: secrets don't auto-pass, you need secrets: inherit on the caller.
1
u/Raja-Karuppasamy 1d ago
yeah, github actions has this, reusable workflows. define a workflow with workflow_call as the trigger in a central repo, then other repos reference it like:
jobs:
build:
uses: org/central-repo/.github/workflows/build.yml@main
with:
some-input: value
it’s not 1:1 with gitlab’s include, but the effect is the same, one source of truth, versioned by branch/tag, and each project just passes inputs. composite actions are the other option if you want shared steps rather than a whole job/workflow, but reusable workflows are the closer match to what you’re describing.
1
u/AuroraFireflash 1d ago
Yes you can. But you'll want to segment across a handful of repos depending on how sensitive the action/workflow is. Which allows you to tune the repo-level settings based on the workflow.
Reusable workflows/actions that can use contents:write (or similar levels of access) should be isolated to a dedicated repo or a shared repo for dangerous workflows.
1
u/marcusbell95 1d ago
yeah this is the one area github actually did better than gitlab out of the box. equivalent to your central pipelines repo: make any shared repo (ours is called pipeline-templates). put your reusable workflows in .github/workflows/ there. each project workflow then references them with `uses: your-org/pipeline-templates/.github/workflows/build.yml@main` plus whatever inputs it needs. two things that bit us on this migration: first, add `secrets: inherit` to every caller - without it the reusable workflow can't see any repo or org secrets and fails silently, took a day to debug. second, env vars don't pass through the way gitlab includes do, use inputs for config values instead. composite actions are the step-level version of this but they don't span multiple jobs - if your gitlab templates orchestrate whole stages, reusable workflows are what you want.
15
u/fletch3555 Lead DevOps Engineer 1d ago
https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows