Live data from Hacker News

Gitlab 9.0

about.gitlab.com

81–90 of 164 posts

Re: Gitlab 9.0

#81
post #79

I am having problem with de CI/CD after update: ``` Running with gitlab-ci-multi-runner 9.0.0[...] Cloning repository... Cloning into '/builds/xxxxxxx'... warning: You appear to have cloned an empty repository. Checking out xxxxxxx as master... fatal: reference is not a tree: xxxxxx ```

I rebooted de entire machine and it is working now

Re: Gitlab 9.0

#82

I'm surprised, impressed, and frankly amused in that you can sign into gitlab.com with your github account.

Glad to hear that. You can also import your projects directly (everything will be copied over). We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.

>You can also import your projects directly (everything will be copied over).

I had forgotten about that, thanks for the reminder.

I'll be moving all my stuff over this weekend once I curate out the things I don't actually use over on Github...

Re: Gitlab 9.0

#83
I love and use Gitlab and am excited about the 9.0 performance improvements.

On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix.

I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one-off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request.

Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_r...

Re: Gitlab 9.0

#84
The new enhancements seem very promising. We've been using gitlab for our internal use for a while now.

Having said that, every time a new gitlab release comes around, I always looks for updates in one area expectantly but mostly left unsatisfied. And that is, separation of the concept of Project from "one git repo"

E.g., I want to manage a project that ties in issues from various different git repositories. It's pretty common. Almost no actual "project" in a real life business is limited to just one git repo.

I want a system-wide wiki that collects knowledge about the entire operations. The idea that each wiki is tied to a particular git-repo is.. just... wrong.

Heck, even the new search feature across projects somehow doesn't include wiki's. How did that decision get made?

And so on and so forth.

Re: Gitlab 9.0

#85
post #46

Earlier quoted context omitted.

Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?

You bring up a good point -- nginx proxying won't help for connections made over SSH (which is a large portion of our deployment)

Good point. However, I guess recent nginx supports streaming tcp proxy, so maybe it would work. http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html

Re: Gitlab 9.0

#86
post #6

Earlier quoted context omitted.

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

What's a similar editor that's faster? VS Code?

Re: Gitlab 9.0

#87
post #35

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a si…

"Since Gitlab projects are repo-centric"

This seems to be the huge blind spot on gitlab product design. Everything is tied to git repo's while in the real world installs, users want global views of things which go across git-repos. I suspect this comes from starting off as a github clone, which has it's own constraints as a product (and it's public face).

Re: Gitlab 9.0

#89
post #46

Earlier quoted context omitted.

Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?

If I remember right, nginx doesn't support ssh + http(s) on the same port. I'd be happy to learn this isn't correct, though because my personal server only is allowing http through.

You can actually distinguish between those on a single port using http://nginx.org/r/ssl_preread and some sslh-like checks using e.g. njs.

Re: Gitlab 9.0

#90
post #6

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did…

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

Taking a look at Gitaly & the conversations around it, I don't see much in the way of consensus. Are you using Redis for the distributed lock or is this still a centralized system?

My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.

Post reply on HN