5 ms·

Nice. It keeps getting better with each release. Speed seems to have improved. The only place where github is better is in the UX. Gitlab is ugly on a small lap

by slyzmud 10y ago

Nice. It keeps getting better with each release. Speed seems to have improved. The only place where github is better is in the UX. Gitlab is ugly on a small laptop screen, in issues view it has three top bars that becomes really annoying. It reminds me old IE days when you had a lot of bars. Apart from that, everything is amazing, I use it daily, specially Gitlab CI, which is one of the best CI ever.

sytse 10y ago
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/ 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/ 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 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 https://blog.captaintrain.com/12703-building-on-gitlab-ci
- ryanmaclean 10y ago
  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.
  - sytse 10y ago
    Thanks Ryan!
- dominotw 10y ago
  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.
  - sytse 10y ago
    I think there are a couple of ways to cache: 1. Build artifacts (recommended) http://docs.gitlab.com/ce/ci/build_artifacts/README.html 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/336#note_12195101 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/... 3. Single Runner Caching https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md 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 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-registry/ 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/20155
    - Snappy 10y ago
      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.gitlab-ci.yml 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).
- allendoerfer 10y ago
  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
  - sytse 10y ago
    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 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.
    - allendoerfer 10y ago
      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.
      - sytse 10y ago
        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 https://gitlab.com/gitlab-org/gitlab-ce/issues/20154
- drewcrawford 10y ago
  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-22%20at%206.02.27%20PM.png http://weblinksdca.s3.amazonaws.com/Screen%20Shot%202016-07-...
  - whost49 10y ago
    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 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.
    - tenken 10y ago
      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 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.
    - drewcrawford 10y ago
      I have it set to 2 already :-) Unfortunately I still ENOMEM at least once a day.
- lloeki 10y ago
  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 https://github.com/arch-osx)
  - sytse 10y ago
    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 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_13078431 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 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 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 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 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.

by slyzmud 10y ago

sytse 10y ago

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/ 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/ 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 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 https://blog.captaintrain.com/12703-building-on-gitlab-ci

ryanmaclean 10y ago
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.
- sytse 10y ago
  Thanks Ryan!
dominotw 10y ago
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.
- sytse 10y ago
  I think there are a couple of ways to cache: 1. Build artifacts (recommended) http://docs.gitlab.com/ce/ci/build_artifacts/README.html 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/336#note_12195101 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/... 3. Single Runner Caching https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md 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 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-registry/ 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/20155
  - Snappy 10y ago
    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.gitlab-ci.yml 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).
allendoerfer 10y ago
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
- sytse 10y ago
  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 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.
  - allendoerfer 10y ago
    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.
    - sytse 10y ago
      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 https://gitlab.com/gitlab-org/gitlab-ce/issues/20154
drewcrawford 10y ago
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-22%20at%206.02.27%20PM.png http://weblinksdca.s3.amazonaws.com/Screen%20Shot%202016-07-...
- whost49 10y ago
  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 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.
  - tenken 10y ago
    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 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.
  - drewcrawford 10y ago
    I have it set to 2 already :-) Unfortunately I still ENOMEM at least once a day.
lloeki 10y ago
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 https://github.com/arch-osx)
- sytse 10y ago
  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 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_13078431 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 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 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 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 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.