[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