71–80 of 127 posts
Cool, requirements management is coming! Not cool, it’s only in Ultimate. No way am I going to be able to get my company to shell out for that.
Earlier quoted context omitted.
We released DAG as an MVC, which helped a lot of people out even in its current state. We do release features here iteratively intentionally, with the idea that feedback will help make future iterations better in unexpected ways compared to if we released a big feature all at once. The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716 . Your feedback on seque…
It's not that the DAG feature isn't useful to me, the problem is that it has to coexist with a badly engineered version (the stage based model) which should never have been released in the first place. It is better to have GitLab not support CI runners than it is to push something that is so badly engineered. Better to delay that feature for 6 months than to increase the amount of legacy you push downstream to your u…
Releasing early to get feedback on issues is important to us but we can do better communicating around what's an early preview vs. a mature feature. The maturity page that's linked to in this discussion is actually part of how we are trying to improve our communication around that. This is more at the stage and category level, but features have a maturity level as well and it's worth us reflecting on how that can be made more clear.
I love using Gitlab SCM, but I'm surprised that Gitlab CI is described as "Lovable" while major bug fixes are gated for months on an uncertain future feature release: "Job marked as success when job terminate midway in Kubernetes" https://gitlab.com/gitlab-org/gitlab-runner/issues/4119 IMO a production CI bug that falsely reports success merits a high priority patch release but Gitlab doesn't seem to see it that way.
The runner self-modifies the config file and uses it as state which makes it basically impossible to deploy it in an immutable way (Like on nixos). I found out that most config options (but not all of them) are also avaible as environment variables and cli flags so that's how I hacked around the issue but it means I can't support all features that the runner has because the environment variables do not expose all the available config options.
The fact that it's so hard to automate a piece of (in theory) stateless software is really annoying :(
https://gitlab.com/arianvp/nixos-gitlab-runner https://gitlab.com/gitlab-org/gitlab-runner/issues/1932 https://gitlab.com/arianvp/nixos-gitlab-runner/issues/2
Earlier quoted context omitted.
I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own s…
We released DAG as an MVC, which helped a lot of people out even in its current state. We do release features here iteratively intentionally, with the idea that feedback will help make future iterations better in unexpected ways compared to if we released a big feature all at once. The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716 . Your feedback on seque…
Kubernetes story is quite telling. They released "cloud native charts" a year or so ago , that is their official way to run Gitlab on Kubernetes, yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update. That is what their customers were sold under the label "ready for Kubernetes".
Same goes for almost every feature.
Earlier quoted context omitted.
My impression is the opposite. Compared to Github, Gitlab is simply phenomenal, especially the UX. It's honestly one of the few pieces of software that I truly enjoy using every day.
Enabling "AutoDevops" on ALL existing projects and wasting runner minutes people payed for is indeed "phenomenal".
https://docs.gitlab.com/ee/user/admin_area/settings/continuo...
Gitlab is slow. It’s so unbearably slow, even their official server. Guys, why should a static content load after page loading is done? Page loading done, and the code still loads with a loading circle. Why? Just compare it with github. Average 500ms makes a huge difference. Also gitlab UI is a huge mess. It got all the features, sure. But the UI is not that user friendly. Don’t use flat the wrong way. Use contrasts…
Gitlab isn't big company, 100 devs or so, they try to target much bigger fish (>2000 devs) with their product, yet they can't make it work even for their scale: Kubernetes , monitoring, CI workflows like merge trains and others. So when it comes to putting you money (gitlab.com subscribers) where you mouth is (gitlab.com/features page) they are not there yet. Kubernetes story is quite telling. They released "cloud na…
384 engineers, out of a total of 873 employees. I'd say that's a pretty reasonable size.
Earlier quoted context omitted.
Enabling "AutoDevops" on ALL existing projects and wasting runner minutes people payed for is indeed "phenomenal".
Turn is off then? https://docs.gitlab.com/ee/user/admin_area/settings/continuo...
Besides, if you manage to find their issue you'd see carnage this decision caused for some of the customers. Even those with own runners found them swamped in jobs doomed to fail , blocking actually inportant pipelines.
Autodevops as a product feature targets very niche audience of teams running gitlab, but without dedicated DevOps team , it is by definition a very opinionated view on CI/CD and I can not see how it was acceptable to suddenly enable it on all existing projects on whole gitlab.com overnight.
I love using Gitlab SCM, but I'm surprised that Gitlab CI is described as "Lovable" while major bug fixes are gated for months on an uncertain future feature release: "Job marked as success when job terminate midway in Kubernetes" https://gitlab.com/gitlab-org/gitlab-runner/issues/4119 IMO a production CI bug that falsely reports success merits a high priority patch release but Gitlab doesn't seem to see it that way.
Getting Gitlab CI to work has been a major PITA for me. I would maybe give it a quarter circle in its current state. Not a heart. The runner self-modifies the config file and uses it as state which makes it basically impossible to deploy it in an immutable way (Like on nixos). I found out that most config options (but not all of them) are also avaible as environment variables and cli flags so that's how I hacked arou…
In particular UX of a runner registration was improved with config template feature https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...
There is still a problem, that self modifying config option doesn't fit nicely with Nix though