#random (2023-03)

I like #ai the attention is all on chatGPT right now but I imagine we will be looking at a number of different providers/tools/models beyond what openAI offers.

We did it! ai is a thing now, come share your experiences!

I just can’t imagine coding anywhere except GitHub, and for that reason can’t imagine using something like GitLab CI in my repos. Even if it is compatible, the context switching isn’t worth the potential benefits.

GitLab integrates with GitHub now and is far superior to GitHub Actions (as of today)

https://about.gitlab.com/solutions/github/

why far superior? what sets it so far apart from actions?

Flexible code reusability much more fluid and extensible than what Actions offers at least last time I reviewed it they only had Workflows which in my opinion is very gimped. If you are managing uniform pipelines across a large userbase not being able to standardize and extend is crucial.

I think Actions will be at parity with GitLabs offering one day but I do not feel like it is there yet. It is not a slight on the product. They offered this several years after GitLab.

I don’t have the side by side feature list, but Gitlab has had a lot more time and resources put toward their CI offering. How many years was Gitlab running for before GHA entered the market?

I’ve only got experience in GHA but they have been advancing pretty rapidly in the few years I’ve been working in it. The context switching disadvantage is enough to make it really hard for me to consider anything else.

Re: reusability, that’s one area where GHA has definitely made strides. Composite actions and workflow_dispatch come to mind.

GitLab CI is pretty cool. I think composite actions and reusable workflows allow GHA to offer much of the “reuse” functionality one might get from GitLab CI.

The one thing I prefer with GHA over GitLab CI is the ability to trigger on just about anything. Does GitLab CI only trigger on repo activity like push, MR, etc?

The next thing is that the workflow definitions can be located in different files. That is, i feel like GitLab CI only has the one file, .gitlab-ci.yml, while GHA workflows can be defined by any YAML file located in .github/workflows. Working with GitLab CI, I felt like I always had to add additional logic to the one file to keep from running jobs/steps that I didn’t want to happen on every push. The branch protection logic is similar but I like the ability to have specific workflows in specific files (GHA) vs all workflows in one file (GitLab CI).

@managedkaos the GHA link you provided is basically exactly how Gitlab operates. It gets more specific, if needed, via rules paradigm https://docs.gitlab.com/ee/ci/yaml/#rules

Also, gitlab is more flexible rather than having a .github/workflows folder.. you can have a monorepo and have a specific pipeline per folder in the monorepo and include them depending on the rules : https://docs.gitlab.com/ee/ci/yaml/includes.html

If GHA has a feature.. then Gitlab probably had it years earlier already

rules is relatively new to GitLab so he might have converted to Actions before that went live

i guess what I’m getting at is, GHA has triggers for just about anyting that can happen against a repo. for example, if someone creates an issue, you can run a workflow.

is there a similar feature in GitLab CI?

@rms1000watt @timduhenchanter do you two use Gitlab for VCS as well?

At one place: no At other places: yes

it was fine in all setups

@managedkaos I would imagine all that can be done with Github webhook integration (If we’re talking about GitLab CI+GitHub Repo) but that’s a bit of work. Unless Gitlab has some convenient Github App that can manage all that

Like for simple pipelines, GHA is just fine

I am using Jenkins and GitHub at the moment so I will shun myself. However, when I was using GitLab it was also being used for VCS because there was not GitHub integration at the time. I think it’s fine for VCS personally. There are some niceties with GitHub for sure but nothing earthshattering. If I went back to it I would not mind using it for VCS because I would not want to double my licensing costs for GitHub users and GitLab users in order to integrate

But when you have complicated (mono)repos.. you’ll find yourself writing a lot more glue code that’s not necessary using Gitlab

With GitLab you can selectively call stages stored in a central managed repository also so you don’t have to run every block in a job. That has been around for a long time to your previous argument for GHA.

I would imagine all that can be done with Github webhook integration (If we’re talking about GitLab CI+GitHub Repo) yeah i guess that’s what i’m getting at. i would prefer to just stay in one repo vs using github for the code and gitlab for the CI.

and to the point that github gives more options out of the box for workflows on anything that happens in a repo, not use code activity (like issues, comments, stars, etc).

i like gitlab ci, so i’m not knocking it. just thinking that GHA has more features when it comes to triggers.

Yeah I want to move off Jenkins to GHA but I just don’t feel like it has feature parity yet.

well i’m an oddball because i would probably start with Jenkins first. i’ve been using it for years so its muscle memory to go there for CI/CD when i start a new project

Yeah I have a central generalized pipeline in Jenkins that is pretty flexible so if I am working with something Greenfield it’s just the easiest to provision due to years of utilization.

same. i have templates that are rock solid so i just copy pasta in new proejects.