Hacker News Reader

Comment by sytse | Hacker News Reader

Thanks for your kind words. We're working on improving the UX. We recently redesigned the menu https://about.gitlab.com/2016/06/06/navigation-redesign/ and we're hiring more UX designers and a UX lead on https://about.gitlab.com/jobs/

Thanks for naming an example of a view we can improve, I've screenshotted the issue view in http://imgur.com/a/0FREI Suggestions are very welcome.

Glad to hear CI is working out for you. It was great seeing CaptainTrain write about it yesterday https://blog.captaintrain.com/12703-building-on-gitlab-ci

View on HN

Some not too drastic suggestions:

- hide "Open", "Closed", "All" in a status dropdown

- Move the RSS icon somewhere to a dropdown + use a meta tag, people who use it will figure it out

- Move "Filter by name" to the filter menu or even better: switch the top search to "Search issues" with a dropdown to change it again

- Move "Issues, Labels, Milestones" where "Open, Closed, All" was before. Boom, one less horizontal navigation.

- Remove the TODO icon at the top right

- Remove one or two items of the project navigation

- Combine some of the project settings items, especially the lesser used

Wow, thanks Allen for the clear suggestions. My initial thought is that we can do some of these. It would be awesome if we can have one less layer of horizontal navigation. I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/20154 to follow up on this. If you or others have any more suggestions feel free to add them there as a comment.

Sure, thanks. I was trying to only change the issues page and stay within your overall layout.

Additionally I would probably move the user icon from the top right to the left and replace the hamburger, since the navigation below is really the user menu.

Thanks for staying within the overall layout, that makes everything much easier to consider and implement.

I've added your last suggestion to https://gitlab.com/gitlab-org/gitlab-ce/issues/20154

Hey sytse, always glad to see you being so involved around here :-D. Here's some random feedback (not sure this warrants creating some issues, just food-for-thought).

Constant stream of increasingly polished UI updates has been a huge driver for adoption internally.

GitLab is being increasingly used not just for code but also for project management, collaboration and possibly even tier-1 support tasks, and emphasis on features such as email sinks, deadlines and (hopefully soon) label-backed boards is just fantastic. As soon as boards merge we might very well be dropping Trello.

Since it's being increasingly used by non-tech folks, the second bigger barrier to adoption UX-wise over here is localization. Months (years already? time flies!) ago the rationale was that tech teams know english so GitLab was fine with no localization, but things seem to come to a change.

"Codeless" projects is definitely something of interest for non-tech folks too (i.e no git repo/MR/CI but issues and wiki), is that out of scope for GitLab?

Any plans for non-linux (specifically Mac OS X) shared runners on gitlab.com? This is definitively a factor in migrating some FOSS projects from GitHub+Travis to gitlab.com (shameless hint: https://github.com/arch-osx)

Hi Loic, thanks, glad to be here.

> Constant stream of increasingly polished UI updates has been a huge driver for adoption internally.

Yay, glad to hear that. We'll keep them coming, we're hiring UX designers and a UX lead at the moment.

> GitLab is being increasingly used not just for code but also for project management, collaboration and possibly even tier-1 support tasks, and emphasis on features such as email sinks, deadlines and (hopefully soon) label-backed boards is just fantastic. As soon as boards merge we might very well be dropping Trello.

Wow, that is awesome to hear! The issue board is landing in 8.11 https://gitlab.com/gitlab-org/gitlab-ce/issues/17907 and the latest mockup looks pretty sweet https://gitlab.com/gitlab-org/gitlab-ce/issues/17907#note_13...

To do support and email sink would be nice (in addition to reply-by-email that we currently already have). The issue for this is in https://gitlab.com/gitlab-org/gitlab-ee/issues/149 and if you like it I would appreciate a comment with your use case there.

> Since it's being increasingly used by non-tech folks, the second bigger barrier to adoption UX-wise over here is localization. Months (years already? time flies!) ago the rationale was that tech teams know english so GitLab was fine with no localization, but things seem to come to a change.

Translating GitLab is inevitable but we need a good trigger to start. Preferably a large organization that expresses this wish. The conversation is happening in https://gitlab.com/gitlab-org/gitlab-ce/issues/4012

> "Codeless" projects is definitely something of interest for non-tech folks too (i.e no git repo/MR/CI but issues and wiki), is that out of scope for GitLab?

Great idea and a wish of me for years, I've made an issue https://gitlab.com/gitlab-org/gitlab-ce/issues/20182

> Any plans for non-linux (specifically Mac OS X) shared runners on gitlab.com? This is definitively a factor in migrating some FOSS projects from GitHub+Travis to gitlab.com (shameless hint: https://github.com/arch-osx)

If we do this we will likely charge for non-linux runners to make it sustainable. Of course you can already bring your own OSX runner by renting it somewhere and installing GitLab Runner on it.

This is a fantastic example of the reason we went with Gitlab! I wish other products were this pro-active! Keep up the great work folks.

Thanks Ryan!

Hi sytse, while I've got you.

I've been annoyed these last few releases by high memory usage. Every day, my backups fail due to ENOMEM.

I have adjusted unicorn-worker-killer to undo the increased memory usage you did a few releases ago:

    unicorn['worker_memory_limit_min'] = "300*(1024**2)"
    unicorn['worker_memory_limit_max'] = "330*(1024**2)"

(8.9.0's default is a totally absurd 400-650MB.)

and while that stops my server from falling over in the first 10 minutes, it does consistently fall over once a day.

Here is a screenshot of my htop, I'm not sure where to look next. 25% free sounds okay, but it's not enough to run a backup, or even run `gitlab-rake`.

http://weblinksdca.s3.amazonaws.com/Screen%20Shot%202016-07-...

Drew, thanks for sharing your settings. It looks like you are using a 2GB RAM system.

How many unicorn workers are you using? For 2GB systems, I'd recommend at most 2 rather than the default 3. Some discussion about this is here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1279

We'll be doing more work in these coming months to profile and reduce the memory usage needed by GitLab so that all your tools can run comfortably in the 2GB range.

Hi. I have a 2gb synology nas I run Gitlab via docker...i may mod the nas to say 6gb or 8gb ... But trying to avoid that.

My Gitlab backup is ~5gb monolithic .tar.gz daily. Is there any reason the tar.gz is 1 huge file, would using Linux split stop these massive Worker threads and device utilization? http://unix.stackexchange.com/a/61776/86052

An added benefit of splitting to a configurable max size is certain cloud vendors have a max filesize limit...like 5gb :/ when replicating the backup.

I have it set to 2 already :-) Unfortunately I still ENOMEM at least once a day.

Strange, your screenshot shows 0.5GB free. I recommend configuring swap to prevent the system falling over. It shouldn't actively swap much with 2GB unless making a backup or something like that.

hey sytse, how does gitlab ci handle caching of maven,ivy, gem s...artifacts? Does each new build have to download it ?

I see some issues discussions, workarounds and seems like it does allow -cache directories but it is unclear how it all works.

for us( unfortunately) its 40 min vs 5 min build times, with/without caches.

I think there are a couple of ways to cache:

1. Build artifacts (recommended) http://docs.gitlab.com/ce/ci/build_artifacts/README.html

2. Cross Runner Caching (not implemented yet) https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...

3. Single Runner Caching https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... Edit: a better explanation is in http://docs.gitlab.com/ce/ci/yaml/README.html#cache

4. Container registry (not possible for Maven, etc.) https://about.gitlab.com/2016/05/23/gitlab-container-registr...

I agree it is confusing and my knowledge might not be accurate. I've asked CI experts to improve the documentation in https://gitlab.com/gitlab-org/gitlab-ce/issues/20155

First off, I'll admit our documentation for caching needs improvement.

We do support caching of gem's and other file artifacts. There are tricks about file locations, but once you get the hang of it, it works well. See https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Ruby... for an example for Ruby. It's actually one of the sources for our new CI configuration templates!

But sometimes, you don't really want caching, you want artifacts. Caching is an optimization, but isn't guaranteed to always work, so you need to be prepared to regenerate any cached files in each job that needs them.

Artifacts, on the other hand, are guaranteed to be available. It's sometimes confusing because the name `artifact` sounds like something that is only useful outside of the build, like for downloading a final image. But artifacts are also available in between stages within a build. So if you "build" your application by downloading all the required modules, you might want to declare them as `artifacts` so that each subsequent stage can depend on them being there. There are some optimizations like declaring an expiry time so you don't keep artifacts around too long, and using `dependencies` to control exactly where artifacts are passed around. Again, complicated subject that is poorly documented. I'd be happy to help you figure it out for your use case (and then publish the learnings).

Have you looked at using a caching proxy or maven repo in front of GitLab? For our TeamCity builds we have ProGet sitting in front of the public NuGet and Maven repos, it caches the downloads so any machine on our local network can reuse them instead of downloading artifacts every time.

Reply on news.ycombinator.com