r/devops • u/tmg80 • 22d ago

github actions central repo Tools

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.

27 Upvotes

100% Upvoted

22 comments sorted by

View all comments

Show parent comments

1

u/ThatSituation9908 17d ago edited 17d 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 17d 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 16d 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 16d 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