Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s Next for Gitlab CI: Auto DevOps

about.gitlab.com

Post reply on HN
Print view View original

61–70 of 91 posts

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

#61

Post by brodock »

mikepurvis wrote: post #31
cmatija wrote: post #23

Earlier quoted context omitted.

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 b…

GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration.

While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions.

While CI is part of the same product, you don't run the tests in the same machine, so you still need to provide the workers in additional ones or use the autoscalling mechanisms and have it bootstrap machines in the cloud as needed.

So what I mean here is that while it is part of the product, it's mostly the "frontend" and the "APIs", the heavyload part of running it is totally optional.

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

#62

Post by EddieRingle »

sytse wrote: post #58
roblabla wrote: post #43

Earlier quoted context omitted.

I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitla…

Please use the official Omnibus packages to ensure that upgrades are less likely to break. I think we use toml for the Runner since it is written in Go and should be deployed on another server. The rest is mostly in yml files although we trying to move as much as possible to the UI to make it more user friendly.

> I think we use toml for the Runner since it is written in Go and should be deployed on another server.

Couldn't you just parse YAML in Go, or TOML in Ruby? (Or why not give the option of multiple formats?)

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

#63

Post by u801e »

hardwaresofton wrote: post #16
flipp3r wrote: post #6

Earlier quoted context omitted.

Gitlab's UI is absolutely awful and incredibly slow. Would you say the same for other tools, like email, or your IDE or editor? They literally copied every functionality and UI of GitHub when they started out, and the only difference at the time was that Gitlab was a slower version of Github. I'm glad you can self-host it, and that they're open source, they've got that going. But if GitHub would ever open source thei…

A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it). Email, IDE, Editors are not the same as your code hosting, testin…

> Email, IDE, Editors are not the same as your code hosting, testing, deployment tool

Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?

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

#64

Post by dijit »

FTA wrote: post #57
roblabla wrote: post #43

Earlier quoted context omitted.

I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitla…

This was my same experience. I spent three solid work days trying to install it from source since it's on a server with other services and their default nginx etc. setup couldn't work. All the different microservices made installing from source very difficult. I ended up finally giving up and using the black box omnibus installation and fiddling with the configuration file for a while. It works now but I can't hack t…

I gave up and ran a docker container with reverse nginx vhost proxy to the docker port.

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

#66

Post by ibaum »

roblabla wrote: post #43
bartvanH wrote: post #19

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 just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitla…

Thanks for the feedback. I'm on the build team here at GitLab, and we try and keep installation as easy as we can, but GitLab is a complicated application.

One of the benefits of the omnibus package, is that all configuration is done through a central gitlab.rb file. So the different configuration formats for the individual services is not noticeable to the administrator. Unfortunately, this doesn't necessarily translate to source installations.

We try and provide good documentation for building from source when our omnibus package or docker image isn't an option: https://docs.gitlab.com/ce/install/installation.html. Any feedback on issues you might have following this guide is welcome. I don't know that we can fix the different configuration formats, but we should be able to fix hardcoded paths. Any examples you could provide would be appreciated.

We do provide docker images for those on operating systems we do not support. https://docs.gitlab.com/omnibus/docker/. If you're just looking to run the latest version, this might be the easiest way for you to proceed.

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

#67

Post by dimitrieh »

CameronBanga wrote: post #51
cmatija wrote: post #24

Earlier quoted context omitted.

Sorry to hear you're displeased with our UI. We're always looking to improve our UI and UX as much as we can. There's currently a navigation overhaul planned [1]. If you have any other specific suggestions complaints about the UI we'd love to hear about it, you can even open an issue about it yourself [2] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues

Reporting UI issues is a bad experience on GitLab in and of itself. The move to a hamburger menu saw significant outcry, and was followed by one of the more popular tickets I've ever seen on GitLab asking for the ability to restore the menu pin feature. Every complaint and criticism was basically replied with "Nah, we're keeping it.", because the new hamburger menu had gone through "design testing". If you're looking…

Hi, I am from the GitLab UX team. You may be happy to hear that since and even before the implementation you described we have been busy on a real upgrade for navigation across the whole of GitLab.

Rest assured, that we are hard at work at this (see for more information https://gitlab.com/gitlab-org/gitlab-ce/issues/32794). Even better, if I am correct, there will be a new navigation concept (first alpha iteration) released in 9.4! This will be hidden in a feature flag, which will be accessible from your personal settings.

In the coming months (and thus releases, every 22nd!) we will continue to improve upon this concept, to eventually enable it by default for everyone to enjoy.

We know that the shortcomings of the hamburger icon are suboptimal, but also know that reverting is not always the correct choice. With the new navigation concept we focus on getting a clear distinction between global and contextual navigation. We did proper UX testing to be able to clear out multiple bumps in the road/implementation and are pretty stoked about finally getting it in!

Again check for more information this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/32794. The scope of revising navigation is pretty far reaching and has been on the minds of almost everyone on gitlab!

Note that colors, functionality and any specifics can change throughout the process of implementing over the coming months :)

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

#68

Post by claytonjy »

Top19 wrote: post #55

I really like Gitlab. It allows you to organize your repos, and do things like nesting them in categories. Why Github won't add this feature is beyond my understanding, and I really appreciate Gitlab stepping up and adding this into their platform. They also have a great system for migrating your repos over from Github.

This! I'm at a small consulting shop (< 5 ppl), so it's really, really nice to have one subgroup per client; I'd hate having pages and pages of "client1-project1", "client1-project2", ... in a Github setup.

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

#69

Post by sytse »

bartvanH wrote: post #19

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…

We hear your concern about GitLab getting bloated. We first made GitLab CI as a separate application. When Kamil (CI lead) proposed to Dmitriy (co-founder CTO) to add CI to GitLab itself he said that was a bad idea, we need sharp tools. After Dmitriy became convinced and when they proposed it to me (CEO) I had the same response: http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned...

But when we integrated it the sum was more than the parts. The benefit of deep integration and not having to switch applications are becoming more apparent to us. It is hard to articulate why the same can't be done with plugins, the video in the article is maybe a good start.

Review Apps, changes metrics in the merge request, the container registry being aware of your permissions. All this can be done with plugins. But having it in one applications is so much easier to set up, upgrade, and use day to day.

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

#70

Post by wolco »

hardwaresofton wrote: post #17
izolate wrote: post #5

Earlier quoted context omitted.

Bad-ish? Try horrible. GitHub has raised the bar too high for Gitlab to spout the tired developer rhetoric that UI/UX doesn't matter.

Gitlab doesn't spout that rhetoric, and neither am I. What I intended was a little more nuanced, I will restate, this time (hopefully) more clearly: Bad UI on your git hosting tool is very likely not what's holding back your org from delivering faster. It's more likely things like not automating your builds/pipelines/deployment. Maybe you're at a company that's already doing this properly, you've got Github/Bitbucket…

The issue for them is those who don't care about UI are the type who can setup and run there own version of a similiar product.

The crowd that would benefit the most has a modern saas mindset.. simple, fast ui. less clutter..

Post reply on HN