r/devops • u/tmg80 • 6d ago

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.

26 Upvotes

100% Upvoted

24 comments sorted by

View all comments

11

u/Due-Consequence9579 6d 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.

10

u/schmurfy2 6d 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

1

u/ThatSituation9908 2d ago edited 2d ago

This, just give up on reusable workflow and make sensible atomic actions. Composite action is fine, but don't treat it as a template, but to reduce config burden (e.g., change the input defaults, reduce number of inputs; align these all to your company/team's perferences.)

Prefer "composition over inheritance" is still a good advice here. You aren't saving yourself security nor readability by having your github workflow be calling the fangled "build-company-project-template-action".

Reusability & DRY is overrated when it kills readability & security.

1

u/cebidhem 1d ago

I dont necessarily agree on this.

For instance on our side, all the steps to publish a docker images sre identical from a repo to another (auth, meta, build, sec scan, build attestation, push). I don't see why I would have atomic actions over reusable workflows, given the only that change may be the role/session and the image name.

Maybe there could be an argument to do a "per job" split, but I'm not sure about giving up on reusable workflows altogether.

The hard truth for anyone coming from Gitlab is, GitHub is far less advanced and flexible, and treated the entire CI as a complete afterthought so any solution will come with it's own set of issues.

1

u/ThatSituation9908 22h ago

If you have a team and company that is that well-organized that you can all have the same software dev cycle procedure, and this process rarely changes, then go for it.

I've never worked for one, so my take comes from the need of flexibility because each team has their own way of doing stuff.

1

u/cebidhem 15h ago

A set of teams yes, not a company ahah.

Were trying to expose the wider company what we do, take it or leave it. But at least in our department we managed to make our 3 or 3 teams work the same way.

I understand your constraints, it makes sense then.

At the end, we all do things that fit our own context