[sercand]

This is why we left Gitlab.

DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD. We would pay advance features of those (epics, multiple assignee, etc) but we have to pay super expensive top tier which includes unnecessary DevOps stuff. We left and happy so far.

We are using Kubernetes and custom DevOps tools but don’t want to handle things the way that Gitlab does.

[100011_100001]

This is happening everywhere. The current industry cycle is one of scope expansion, moving away from the do one thing well paradigm. This will lead to bloated software that do a little bit of everything but not very well, which will trigger the next industry cycle, of doing one thing well paradigm.

[pojzon]

Ive started working with Gitlab in last few months for new contract and this was exactly what hit me hard.

Gitlab has too many half-baked features. Ive hit those issues at least a dosen times.

From the top of my head:

- Environment variables dont work with triggers

- MS Teams integration does not support multiple channels

- Masking doesnt work for all variables

- Code AutoDeploy quite often just breaks for no reason..

- Kubernetes integration is super poor

I would prefer to have fewer fearures that actually work well and have good support instead of bunch of stuff you have to sometimes wait years for to be fixed (looking at their issue tracker).

[Havoc]

Yup. I’ve hit two of those even in my rather casual home use. (The masking and trigger ones)

Still - I do like it overall

[kjohnstonGTLB]

GitLab Product Leader here - we do focus on MVCs and have built a lot of breadth in our product, that's something we are proud of. I do think we do a good job of pivoting and removing features where appropriate. For example we started with a not-secure-enough mechanism for attaching Kubernetes clusters and shifted to the more secure GitLab Agent for Kubernetes[1], deprecating the certificate method. We also started with a "must install Prometheus and Elk on your cluster" Observability solution and are now (after our acquisition of Opstrace) working to make observability on-by-default[2].

[1] https://docs.gitlab.com/ee/user/clusters/agent/ [2] https://about.gitlab.com/direction/monitor/observability/#pr...

[rrauenza]

Here’s another one of those maddening issues:

https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376

I’ve had to write a wrapper script around each command that polls the cicd job Id and kills its subprocesses properly if the job is cancelled.

[deastman]

Hello - I am the product manager for GitLab Runner. The SIGTERM-related issues have been quite complex due to the different execution environments in which the Runner can operate. Can you add the details of your use case and workaround to the issue below? We need to take another look at this functionality, given the various reports of inconsistent behavior with long-running processes.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27443

[rrauenza]

CentOS7. I've also asked the SCM team at my employer to get us added as a paying customer who would like this looked at, to help prioritize.

I don't know if you just need to do process groups or walk the subprocess tree or what... but generally, this is a solved problem on Linux for things that manage subprocesses... assuming the processes don't manually do something silly like daemonizing themselves. (That's not my use case.)

Linux should be the easiest case.

edit: What is most frustrating is this issue appears to have been opened ~4 years ago.

[apple4ever]

I really love GitLab, but I agree it has too many half bake features, and too many features that are wonky.

We use GitLab at work, and I tried hard to push back against the hate for it, but its hard sometimes when GitLab is just WEIRD, especially in simple things like MRs.

[andrei]

I've heard this talked about before, and I believe there's a phrase for it, but I don't remember. Do you happen to know?

[teknofobi]

Bundling and Unbundling https://stratechery.com/outline/bundling-and-unbundling

[mountainriver]

Yeah this is a really bad direction for gitlab. All of their devops features are terrible. They don’t pay their engineers which is why everything is poorly built.

They should have just focused on being the best vcs. Oh and you get what you pay for. Want to hire a bunch of mediocre engineers? you’ll get a bunch of half baked features

[andrewstuart2]

I'm honestly of the opposite opinion. I have used GitLab for 10 years now and have yet to find something as useful as GitLab's CI/CD, and I've tried (not always by choice) a ton of different options.

Mainly it's because I strongly prefer to orient most of my flow around Kubernetes deployments and namespaces tied to git metadata like commit sha or branch name, and thus far, I haven't found a better more interested way of doing so than GitLab.

[systemvoltage]

What's the distinction between DevOps and CI/CD? I thought CI/CD is DevOps.

[abdusco]

CI/CD is part of Devops. It also includes monitoring systems, keeping them up, maintenance, upgrades necessary to keep the software working.

[itslennysfault]

DevOps is a methodology.

[andrewstuart2]

I think you're mistaken. DevOps is a very specific team allowed to touch the Jenkins box, and is the old branding for what is now SRE which are both just rebranded names for Systems Administration, but with Cloud certifications instead of Cisco and Dell.

I kid. But this is just as much the meme I've encountered as Agile. Some successful company releases a book about something they do that's fundamentally different, and almost instantly enterprises across the globe have a department for that thing with that name. Progress.

[c17r]

SRE jokingly stands for "SysAdmin, Really Expensive"

[kodah]

Real SREs are great. Who wouldn't want a Systems Engineer that codes and can interrogate kernel issues or a Software Engineer capable of writing their own compiler running your operations?

Most companies, even if they hire these people, don't know how to use or listen to them though. What usually happens is they get lumped in with a bunch of Application Operations folks and it sours the idea entirely.

[vosper]

Yeah, this. There's a gulf between people like Brendan Gregg (my go-to example of a "Real SRE") and those I've actually worked with, who anointed themselves with the same title...

As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.

[systemvoltage]

Well, I was trying to clarify this statement from OP:

> DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD.

It reads to me like this: "We don't use DevOps features in Gitlab, but we use CI/CD pipelines in Gitlab". So it is contradicting. As they responded, CI/CD is a subset of DevOps methodology.

I've used Gitlab and didn't know there were more DevOps tools other than their CI/CD features and runners.

I am still slightly confused.

[sercand]

DevOps is whole set of tools. Gitlab includes features like monitoring, code scanning, Kubernetes integration, docker registry, cloud security and protections. And those are $1188 per year per person. By CI/CD I mean good old Jenkins that runs on a computer in the office that builds iOS Apps and uploads them to Apple AppStore (of course current generation of CI/CD is much better). Gitlab CI/CD and runners were there much before this "Gitlab is the one DevOps platform" saga.

Everyone in our company including HR, marketing, design people were also using Gitlab for task tracking. Therefore we need those fancy issue tracking features for better management. This features are in the tier that $1188/year per person. For the features we don't use is not something that we could afford.

[systemvoltage]

Ah got it, thanks. I wasn’t aware that they’ve built all this stuff.

[bogomipz]

I thought the OP was maybe referring to Gitlab's "AutoDevOps" features which were introduced a few years ago. From their site:

>"GitLab Auto DevOps is a collection of pre-configured features and integrations that work together to support your software delivery process."

I remember upgrading a Gitlab instance at that time and ended up with an issue that was the result of the AutoDevOps feature set. It seemed that AutoDevops was turned on by default. My issue was easy to resolve but I remember thinking at the time it was rather opinionated.

[1] https://docs.gitlab.com/ee/topics/autodevops/

[i_like_waiting]

Where did you go instead?

[okamiueru]

Is it really "center part"? I'll admit there is some unnecessary clutter here and there, but it's easy enough to ignore.

What I don't understand is who these features are for, and who uses them. We use the CI/CD parts, but other than that manage everything through k8s, and I wouldn't dare let GitLab a handle it. And, the whole "one click devops", or what it was called, is even more puzzling.

[robinshen]

This is exactly what I am doing for OneDev: https://github.com/theonedev/onedev

[thinkpad13]

I agree with this

so what you guys use for the issue, epics, burndownchart and such?