I like Gitlab, as an absolute noob I'm not really ready to make every mess of a program I use public (as Github requires). I fear that it can and will be used against me. I'm also such a small time user I think paying for Github is too much for my 3 > 200 lines projects. And so you end up at Gitlab. It works very well for me. If I want to, in the future, I can host it myself which is a nice thing. From this update I most like the dark-themed code view, yes I'm a simple man that is just learning how to code.
Gitlab 9.0
151–160 of 164 posts
Re: Gitlab 9.0
#152Earlier 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…
Looks like those last two screenshots are Grafana - do you mind sharing the dashboard JSON for those views? Very cool!
There's also http://arewefastyet.gitlab.com
Re: Gitlab 9.0
#153Any idea how I can upgrade my docker installation on Kubernetes? At the moment in my Helm chart i have specified exat Gitlab and Postgresql version. Do i need to bump postgresql too when changing Gitlab?
Re: Gitlab 9.0
#154Earlier quoted context omitted.
Well, compared to Atom, yes. Two somewhat similar tools with trade offs between them, one of them being speed.
Note that Atom is written in Javascript, so the run time is extraordinarily CPU heavy. Even though many Electron (Javascript desktop framework) apps may have snappy UIs, they're typically even worse than Java for CPU (battery life, etc).
btw: Sublime Text is written in C++, so the performance might be even better than Java.
Re: Gitlab 9.0
#155Re: Gitlab 9.0
#156The 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…
Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are activ…
I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds.
Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space.
Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
Re: Gitlab 9.0
#157Ah! Finally found the culprit :-)
I run my fleet of runners in pre-emptible instances on GCP (they die after 24h).
I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner.
For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register).
Anyways, look like 9 is a cool release, but we won't be upgrading until the sidebar comes back (did a little poll in the team and it 100% was in favour of the sidebar)
Re: Gitlab 9.0
#158We've been using gitlab for most VideoLAN projects, and are moving towards it for all of them (including vlc and x264). A lot of things are great, and going in the right direction, but the issues tracker is really lacking. The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab. And the biggest issue is that they'r…
I recommend Phabricator: https://www.phacility.com/
It has a best-in-class code review tool and a bug tracker with custom fields, permissions, templates, dependencies and more.
Its code review is built on a patch workflow (like the email-based one that the Linux kernel uses) and works very well, especially for large teams. Merge requests are clunky in comparison.
Many large open source projects moved to it, including Blender, Wikimedia, FreeBSD, Haskell, LLVM and more.
I'm using it in production, am glad to answer any questions.
The development team is dog-fooding it: https://secure.phabricator.com/
Example review: https://secure.phabricator.com/D17538 (just picked one at random, there are better examples probably)
Example task: https://secure.phabricator.com/T8783
Wikimedia instance: https://phabricator.wikimedia.org/
Mockups: https://phabricator.wikimedia.org/pholio/
Workboard: https://phabricator.wikimedia.org/project/view/171/
And much more!
The developers (especially epriestley and chad) are very professional and have a lot of experience managing large projects at scale.
Large essay about the workflow: https://secure.phabricator.com/phame/post/view/766/write_rev...
Re: Gitlab 9.0
#159Ah! Finally found the culprit :-) I run my fleet of runners in pre-emptible instances on GCP (they die after 24h). I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner. For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register). Anyways, look like 9 is a cool release, but we won't be upgrading until the sideb…
maktouch: Runner can't connect to GitLab because version 9.0 of Runner requires GitLab 9.0. We've noticed this in the release blog post: https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#git... :)
The reason is that in 9.0 we've prepared a new API for Runner requests (as part of new v4 version of API) and Runner 9.0 is using only this version.
Version v1 of the CI API is still supported by Runner 1.10.X and 1.11.X. On GitLab's side it will be supported until August 2017 and until then we will also support Runner 1.11.X.
Re: Gitlab 9.0
#160Earlier quoted context omitted.
Which version of gitlab? Didn't they reduce memory demands in a recent release?
I keep it updated; it's now version 9 and still consuming 7G total used free shared buffers cached Mem: 31974 13984 17989 12 871 6047 -/+ buffers/cache: 7066 24907 Swap: 16367 The UI counts 10G for some reason. http://i.imgur.com/edAceQx.png
Our omnibus package tries to use a % of your total memory for cache, so one way to reduce memory is fine tuning it. See for reference: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...