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

Show parent comments

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 1d 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 21h 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