[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.