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

81–90 of 91 posts

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

#81

Post by whatnotests »

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…

This is the kind of software one expects from a team who has never seen how it's supposed to work in real life.

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

#82

Post by roblabla »

ibaum wrote: post #66
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…

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

We have a patch for gitlab in nixos that fixes a lot of our problems. I don't know why we never tried to upstream it, but I guess it's just that nobody bothered. I'll try cleaning it up and upstreaming it when I have some time.

For the omnibus, I'll try looking at how it works, see if it fits our needs better. But I suppose gitaly, which is written in go, still has its own configuration elsewhere, in which you have to replicate the storage list ? That's the sort of thing that I find sort of annoying. It's not a huge issue, but having to manage a bunch of configs, making sure they're all synchronized and up to date sucks as a user experience.

I do have to say, your upgrade guides are very nice and have been helpful when upgrading our instance :).

As far as docker and other things go, I considered it while fighting to get gitlab 9 to work on bare nixos. But the thing is, I manage all my services through nixos, having a central place for all my configuration. This[0] is my configuration (well, a very old one). Everything is in one place, and everything can cross-reference each-other. See my firewall for instance[1], that cross-references various other service's configuration to get their port.

With docker, this is much harder to achieve.

[0]: https://gist.github.com/roblabla/8d1555ceb202eddb1b77

[1]: https://gist.github.com/roblabla/8d1555ceb202eddb1b77#file-c...

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

#83

Post by alchemism »

throwaway91111 wrote: post #73

You know, this feature looks really cool, but the branding "Auto DevOps" seems like word-cloud clickbait and does not actually describe any distinguishing characteristics of the feature. DevOps is already a fuzzy area; what is Auto DevOps? It's at least another order of magnitude of semantic ambiguity.

The origin of "Auto DevOps" does seem to be a product branding creation:

https://gitlab.com/gitlab-org/gitlab-ee/issues/2517

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

#84

Post by throwaway91111 »

alchemism wrote: post #83
throwaway91111 wrote: post #73

You know, this feature looks really cool, but the branding "Auto DevOps" seems like word-cloud clickbait and does not actually describe any distinguishing characteristics of the feature. DevOps is already a fuzzy area; what is Auto DevOps? It's at least another order of magnitude of semantic ambiguity.

The origin of "Auto DevOps" does seem to be a product branding creation: https://gitlab.com/gitlab-org/gitlab-ee/issues/2517

That issue should have basically been in the press release; it's a lot clearer when they dump the branding and focus on actual concrete features they provide.

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

#85

Post by ibaum »

roblabla wrote: post #82
ibaum wrote: post #66

Earlier quoted context omitted.

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

We have a patch for gitlab in nixos that fixes a lot of our problems. I don't know why we never tried to upstream it, but I guess it's just that nobody bothered. I'll try cleaning it up and upstreaming it when I have some time. For the omnibus, I'll try looking at how it works, see if it fits our needs better. But I suppose gitaly, which is written in go, still has its own configuration elsewhere, in which you have t…

The omnibus package is similar to the nixos way of things, except focused on one application rather than the whole system. Once the package is installed, it uses a configuration file, and a set of Chef cookbooks/recipes[0] to configure the individual components.

So yes, Gitaly does come with it's own configuration file that needs to be managed. It does use the same paths as the main gitlab-rails application, so our cookbook has a method to convert the configuration of one to the other[1]

[0]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...

[1]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...

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

#86

Post by pizza234 »

u801e wrote: post #60
dmytrish wrote: post #56

Earlier quoted context omitted.

For personal use, indeed, just use an ssh remote + gitweb interface with basic authentication and that's it. For organizations it makes sense to have something more featureful.

For CI, you could have a git hook that could trigger a Jenkins build. For code review, you could use a tool like gerrit or phabricator or even set up an email list to send patch sets. What other features do Gitlab, Github, or Bitbucket have that wouldn't be covered by that type of setup?

There are no bounds in engineering to how many wheels one can reinvent/reimplement. Ultimately, it's a matter of deciding where to invest the (limited) engineering resources.

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

#88

Post by jamedjo »

foepys wrote: post #11
jmiserez wrote: post #10

Earlier quoted context omitted.

I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well. To the other commenters: Do you have any examples? Also, I’m excited about auto deployment. The less tools one needs to get software shipped, the better.

To see that the UI design is bad at times, take the design of merge requests and issues for example. On Github you can easily see what happens, comments are surrounded by a black border, the name of the comment author and the date are clearly visible and have a different background color from the comment text. Actions like closing and re-opening are distinctly different from comments and are color coded (green -> re-…

This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1]

[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813

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

#90

Post by Snappy »

throwaway91111 wrote: post #84
alchemism wrote: post #83

Earlier quoted context omitted.

The origin of "Auto DevOps" does seem to be a product branding creation: https://gitlab.com/gitlab-org/gitlab-ee/issues/2517

That issue should have basically been in the press release; it's a lot clearer when they dump the branding and focus on actual concrete features they provide.

Thanks for the feedback. Maybe next time we talk about it, we'll be more clear about the features.
Post reply on HN