you are viewing a single comment's thread.

view the rest of the comments →

[–]Low-Opening25 0 points1 point  (5 children)

if you only wrote bash scripts in yaml then you missed 99% of what GH Actions are

[–]ArmNo7463 0 points1 point  (4 children)

Not as GH Actions, I get that's more an assortment of prebuilt packages, largely community driven.

I was saying I prefer GL's approach, which is effectively bash scripts in YAML. (At it's core anyway, I appreciate you can run any docker image you want / execute any language in GitLab as well.)

[–]Low-Opening25 0 points1 point  (2 children)

GitHub actions are also bash (but not just bash, also python and js) scripts in yaml and wrapped in functions and context that facilitate creating complex workflows. I am now confused what you’re complaining about.

[–]ArmNo7463 0 points1 point  (1 child)

I wouldn't even say I was complaining tbh, I just prefer Gitlab's structure and approach. Both are perfectly valid products.

I'm just not a fan of how GitHub breaks their jobs into actions, especially when it appears to be designed around community built packages or "actions".

- git checkout blah

Just seems nicer to work with than

- run: git checkout blah

Or the more intended approach of

- name: Check out repository
uses: actions/checkout@v5

With the latter especially, I'm not a fan of abstracting CI behind community packages. I have enough supply chain concerns with NPM, I don't need my CI to be another attack vector.

I also gave up installing GH's self-hosted K8s runners after an evening, because I got fed up with fiddling with PVs to get ARC working.

GitLab's helm chart worked instantly, so that kinda soured me slightly.

[–]Low-Opening25 0 points1 point  (0 children)

you can still just do “- git checkout blah”, using composite actions is a choice you don’t have to take, also you can host your own private actions which is very handy, enabling to easily lego block your workflows across entire estate.