Live data from Hacker News

What’s Next for Gitlab CI: Auto DevOps

about.gitlab.com

31–40 of 91 posts

Re: What’s Next for Gitlab CI: Auto DevOps

#31
post #23

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed. But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be…

GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2]. If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope [3] - https:/…

As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external.

Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to.

And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.

Re: What’s Next for Gitlab CI: Auto DevOps

#35

I would imagine that git dominates self-hosted git. I just have bare repos on servers I can ssh into. End of problem.

Of the 2 employers I've had who self-hosted, they both did this. I've also done this when self hosting, it's super easy.

I guess there are probably no surveys of this though...

Re: What’s Next for Gitlab CI: Auto DevOps

#36

OP here, just to note - I'm not an employee or affiliated with Gitlab in any way (outside of considering working for them once) -- just a rabid fan. I've been at companies where I've tried (and failed) to convince other developers/higher ups that something like automatically creating an instance of an app based on the feature branch (what Gitlab/others are calling a "review-app"), is the best way to test individual f…

> Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that)

If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much.

I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past.

> Gitlab is slow.

The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com. It's meant to be a viable alternative to GitHub EE.

Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com to https://gitlab.com (that's the impression I get).

By doing that, you've now said "any comparisons between https://github.com and https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short.

If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com as a replacement for https://github.com is going to just cause problems.

Re: What’s Next for Gitlab CI: Auto DevOps

#37

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed. But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be…

I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/.

First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP).

If you also consider the sudden removal of the backlog from the issue board a while ago (they added it back since), I'm now afraid to update our Gitlab instance.

This is very unfortunate because Gitlab is a very nice and useful tool but if QA doesn't improve, it will be very difficult to prevent a migration. These problems are show stoppers for us.

Re: What’s Next for Gitlab CI: Auto DevOps

#38

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed. But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be…

I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/. First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP). If you also consider the sudden removal of the backlog from the issue board a while ago (they adde…

My Gitlab instance broke 3 times in 5 months, and my questions/issues haven't been answered. I had to manage to backup my data, fully uninstall Gitlab and reinstall it. I then hosted it on a dedicated server using docker and it has been running much better since then.

Re: What’s Next for Gitlab CI: Auto DevOps

#39
post #38

Earlier quoted context omitted.

I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/. First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP). If you also consider the sudden removal of the backlog from the issue board a while ago (they adde…

My Gitlab instance broke 3 times in 5 months, and my questions/issues haven't been answered. I had to manage to backup my data, fully uninstall Gitlab and reinstall it. I then hosted it on a dedicated server using docker and it has been running much better since then.

We run Gitlab in an LXD container with an Omnibus install. Everything works pretty well but those issues were caused by regressions in updates. There were new updates fixing those regressions within a few days but it still caused us quite a few headaches.

Re: What’s Next for Gitlab CI: Auto DevOps

#40
post #23

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed. But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be…

GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2]. If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope [3] - https:/…

I would prefer different tools for different stages in the software lifecycle that can be changed independently from each other because they only talk in simple protocols. Everything-Included tools converge to IBM or SAP products that do nothing really well and trap you into their solution because the integration is too tight.
Post reply on HN