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

51–60 of 91 posts

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

#51

Post by CameronBanga »

cmatija wrote: post #24
siliconc0w wrote: post #3

Earlier quoted context omitted.

The UI is bad period. 85% navigation on a normal laptop display (1080). There are layers and layers of menus and submenus which could easily be combined and make little sense. And i'm not even someone with a 'design aesthetic'. The 'review-app' pattern is interesting but doesn't scale for more complicated apps. You'd need to create a 'review cluster' for every branch which quickly becomes untenable. It's usually not…

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 to improve UI/UX, the design team should look through those tickets and learn how to listen when so many users are speaking up against a redesign.

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

#52

Post by [deleted] »

corobo wrote: post #46
wonko1 wrote: post #35

Earlier quoted context omitted.

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

It's super easy for you. I tried to set this up but it's such a pain in the backside to tell people how to pull the latest code. Ended up with Gitlab and haven't looked back. I didn't even realise Gitlab doesn't have auto-deploy yet.. We set up a .gitlab-ci.yml script that deploys the code.

[deleted]

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

#53

Post by wickchuck »

We've been on Gitlab since version 5 and for the most part it's been a pleasure to work with. The omnibus version has made things way easier to install/upgrade, so not sure what the fluff is about being hard to maintain. The UI is adequate and they are working on improvements to smooth out the rough edges a bit. Looking forward to the improvements and new features to come. Just wanted to post something positive instead of the nit picky hate I've been seeing lately about Gitlab...

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

#54

Post by jancsika »

For some reason, different parts of the Gitlab CI software expect different names for the runner binary-- possible names are gitlab-ci-multi-runner and gitlab-runner.

If you set up a runner in a VM and want to upload artifacts, for some reason Gitlab CI requires you to install gitlab-ci-multi-runner on the VM guest (even though it is the host that is actually the runner). But when you do that, you have to actually go through the entire build process before seeing a non-terminal error that gitlab "couldn't find gitlab-runner". So now you have to go in on the VM guest, manually create a symlink from gitlab-ci-multi-runner to gitlab-runner, take a new snapshot of the VM state, and artifact upload will now work.

I say "non-terminal" above because a failure to upload the artifact doesn't fail the build. So you can be looking at all checkmarks for everything in your pipeline and have no idea for which of those jobs you actually got artifacts.

Also, every once in awhile I'll get failed builds where there is nothing at all in the build log. Typically, clicking "Retry" will successfully start a new build and complete successfully.

Also, there is no way to specify to gitlab to keep only the last N artifacts.

On the positive front, I finally figured out a way to set up an ssh server from within the msys2 environment in Windows, which requires no development whatsoever on the gitlab-ci infrastructure. That means gitlab-ci will ssh into msys2 on the runner, giving me a POSIX-y build environment on all my platforms. So that's nice.

Sorry if this sounds overly negative and like a poor substitute for actually filing bugs. But the last time I worked on fixing a bug it took months for the maintainer just to click a button. This seems to be the only place I get timely response.

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

#55

Post by Top19 »

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.

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

#56

Post by dmytrish »

willvarfar wrote: post #34

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

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.

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

#57

Post by FTA »

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 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 the source to make custom improvements, so it ends up not being as open source as I would have hoped. There's one particular issue in trying to push that results from being on a URL subpath (http://.../gitlab). I can't fix it myself because of that.

Don't get me wrong--it's a good program and has worked for the team I support. But click and deploy is not useful for people who don't have bare bones servers they can spin up and instead have to work with shared servers.

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

#58

Post by sytse »

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…

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.

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

#59

Post by foepys »

svesselov wrote: post #44
foepys wrote: post #11

Earlier quoted context omitted.

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

I appreciate the thoughtful and specific feedback. We are working hard to make merge requests and issues intuitive and easy to work with. Many of your observations regarding merge requests are being worked on as part of this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/33095

I'm really sorry that I cannot help by posting this on your issue tracker but I don't have the time right now to sift through all relevant issues on Gitlab to find out where to post and what already has been posted.

My biggest gripe is just that the issue elements (comments, actions, label changes, description edits) are looking too similar for a quick glance. The light-grey font on a white background makes it pretty hard. My suggestion would be to do it a bit like Gihub and to add a black border around stuff, take another background color for actions, and get rid of the grey font and replace it with black throughout.

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

#60

Post by u801e »

dmytrish wrote: post #56
willvarfar wrote: post #34

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

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?

Post reply on HN