It's fantastic for us that Gitlab keeps putting pressure on Github. I hope they keep this strike for a long time. Having said that, they really must improve the performance. I tried to make the switch from Github to Gitlab a couple of months ago, but the general speed and responsiveness is just below the line.
Just want to say thanks for your work! Looking at these slides I really appreciate the openness and the effort you put into gitlab. I'm running a small instance and it's been a total hassle-free experience so far, every issue I had was documented or had a ticket with details to figure it out!
Your education pricing is also stellar, once I got more users I'll look into migrating to EE (at the moment CE+CI is more than fine).
Was happy to see 8.9 downloading on apt upgrade today, not a lot of project updates induce such a reaction, it's usually fear ;) but gitlab never broke on me!
Okay, this comment starts to sound like some paid troll comment for cherishing you but I'm really happy.
Well one nitpick though: I'd love to see some love for the Wiki - it's usable but not up to scratch - asciidoc doesn't really work well and I'm missing something like recent changes and some page tree. I guess it's gollums fault but either better documentation for the workflows or improvements there would be very welcome! Having a great usable Wiki would set gitlab apart in a positive way IMHO.
> We've been using static websites a lot ourselves instead of wiki's pages.gitlab.io
Sure I can understand that it's not a priority but I don't think wiki and static pages have to exclusive - we have a lot of non-technical users and e.g. pushing a static version of the wiki to gitlab pages would ease creation of documentation, so users can use the editor and markdown and the preview to write the wiki and everything gets rendered into some nice static content.
It's basically what you can do now with a regular repository but sometimes it's nice to have docs and code separated.
I'm afraid users don't have the time/opportunity to try the same service over and over again. If a service didn't work for them, it's mostly sure that they're not coming back.
Thanks. We are the speed of GitLab.com is below the line. As you see in the post we're working hard to make it better. Performance of single tenant GitLab installations should be good already.
gitlab is gearing up to be the one-stop-shop from development to production. i really like that. unifying the toolset developers and ops have to understand is really a boon for everybody involved.
merge restriction as a feature may sound silly, but in my experience, when driving organizations toward CI/CD, especially with "mature" organizations, having the computer say no instead of a human is a major facilitator in adoption of good practices. now we just need to protect tests in tree. (currently, i tend to favor tests as a git submodule, so we can prevent chronic offenders from altering/commenting tests that should pass)
plus U2F integration, so now i won't hear anymore how "terribly slow" it is to have to whip out a phone to grab a TOTP code...
Ability to enforce code review (allow users to approve merge requests but not push directly) has been demanded since 2014 [1]
with no support from Gitlab. However, it looks like there's now a chance it's coming soon. [2]
if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals.
it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.
With protected branches you can prevent force pushes to master. You would have to do a manual merge and then git push origin master to cause a problem I think.
I don't generally use feature branches on solo projects. Working directly on master (and pushing origin master at arbitrary moments to back up my work) is a deeply ingrained habit.
A code review tool that's off by default and trivial to bypass in your sleep is a poor code review tool.
This is easy to prevent in Phabricator, which will block pushes to master if they contain changes not also present in an approved unit of code review. I run into that wall a few times a week, and am reminded to move my commits into a branch.
i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.
> plus U2F integration, so now i won't hear anymore how "terribly slow" it is to have to whip out a phone to grab a TOTP code...
I don't know if this applies to you, but 1Password 6 has support for generating TOTP passwords (they have a neato QR scanner built in, or one can always just input the key or key URI by hand)
It's been a revolutionary change in my day-to-day frustration level
yeah i read the scope. but since the border between scheduling, configuration management, monitoring etc... is extremely blurry, with a high number of interconnection between systems, and lacking any kind of standard contract between them, i'm more wary about the introduction of these features.
The idea is to not do container scheduling in GitLab. We're considering adding some monitoring. Standard contracts are not easy but I think it is doable. We already shipped deploy to Kubernetes https://about.gitlab.com/2016/03/22/gitlab-8-6-released/ and we're working on more. For more information about our deployment vision please see about.gitlab.com/direction/cicd
firefox has a plugin that works fine from what i've heard from the others. i still rely by default on totp for generic dual factor auth, since i can provide already working solutions from web to ssh authentication. however, yes for web applications, some clients went the u2f options, and the users overwhelmingly prefer it. since u2f is getting very quickly traction in products (case in point, gitlab) and the user experience is so simpler for a similar level of security, it'll probably become my go to in the near future.
I really like GitLab, but again like with the last release there is no Raspberry Pi 2 package. Even though it's officially supported platform it lacks behind over 2 minor versions by now (8.7.7).
Will repo deploy tokens ever be a thing? I would like read-only deploy tokens associated to a repo, and not a user. I just don't like having to create dummy users with repo access to generate deploy tokens.
How often is File Locking needed? I thought that was one of the beautiful things about Git - merging de-conflicting is not only a thing, but easy to do...
Unless you've worked in Enterprise, you'll be surprised by what is important. And this is actually an important feature, in my opinion.
Enterprise is all about reducing risk and that's because, a screw up can bring down an entire company. There is a reason why they get ISO certified among other things.
In the post, they talk about using locking to signal intent to change, which is also very important in enterprise. In enterprise, you have domain experts and they know if you muck around with a certain variable setting and if the value isn't correct or is just off, it can make their job and others a pain in the ass.
So if you are a domain expert and if there is a trivial way to ensure people don't ruin your day, you'll use it.
Locking is also useful for locking down certain parts of your software, which is something verification would normally insist on.
Mistakes happen and in the open source world, it's a shrug off the shoulder, in enterprise, it translates into loss money.
A little feature I'm missing is to have the code coverage percentage in the slack message
A bigger one is the fact that the comment text area in code review is terribly slow on my very recent desktop in firefox, and unusable on my cellphone (it used to be ok one years ago)
I can't wait to deploy this release (we always wait one week after each release official date, just to let one or two bugfix release).
Thanks @allan_s we are aware of the slowness of the diff tab. It is something we are actively (this very second) working on. I am not aware of the slowness of the text area. Can you create an issue to show us so we can fix it? https://gitlab.com/gitlab-org/gitlab-ce/issues/new
Yes I think for most software waiting for the .1 release is mostly safe.
Thanks a lot once again for the deployement process of gitlab, just having to do apt-get update/upgrade is such a wonderful things, most of project should learn from you, as too often in companies you start to freeze at one version, because the upgrade process is too much mind taking and soon nobody remember how exactly one can upgrade it.
I discovered GitLab on Azure Marketplace (of all places...) and have fallen in love with it for managing PowerShell and other Windows automation projects done in Visual Studio Code (of all things...). To really use it though, I have to get it installed on-prem, and our Unix server guys do not like the default user and group names they saw on the VM: they insist that they have to be max eight characters, no dashes. I'm not going to argue that it's sensible, just that it is :)
It looks like I can use the manual install process - any of you guys done that lately, using user/group names different from the defaults?
Also, they want the stuff installed on an NFS share, not the OS partition. Reasonable, or unreasonable for GitLab?
I'm glad you love using GitLab to manage your automation projects. Luckily, you can still use the Omnibus install but change the default usernames :) In `/etc/gitlab/gitlab.rb` we have the following configuration options:
Change these to acceptable values and it should work well for you. If there are any other blockers in the Omnibus package, please create an issue at https://gitlab.com/gitlab-org/omnibus-gitlab/issues and we'll do our best to accommodate them.
I know this really isn't the place for this, but since sytse and other Gitlabbers frequent these threads it'd be nice to get a response. I've had an open issue on Gitlab for four months now that basically makes it unusable for me:
Sorry about this. I see that GitLab team members worked on the issue and considered it closed but that the problem persists. I've asked our support lead Jose to look into it.
Thanks for yet another very smooth upgrade! I even forgot to back up the server and I have nothing to regret. I just hope that you'll fix this one tiny UI problem I noticed:
Can someone explain me why workers where only alive for 6 seconds? Even now: Why are they only alive for 20 minutes and why is that even acceptable? Is it due to memory leaks?
I'd probably instantly lose my job if any of my systems would crash that often without me fixing it, regardless of the reason...
The unicorn workers are leaking memory. Any worker going above a limit will be restarted. Obviously it would be better to reduce the memory leaks further and we welcome help with that. To be clear, it is not a crash, all requests are handled without error to the end user.
My most wanted feature is manually (from a gitlab ui, not api) triggered build for deployment. Is it just me, or am i missing some good practice that people can live without it?
Recently we added a feature that makes it possible to trigger a new pipeline from UI. It can solve your problem. We are also working on extending our support for environments, so if you need a more flexible solution, stay tuned!
Interesting features. My GitHub student discount with free private repos expires tomorrow, so I'll be finally migrating all my private repos to GitLab tonight.
In general we don't do features that are specific to a certain programming language. But I see the appeal of a npm/gem/apt/yum/jar server. Maybe someone will contribute it.
Keep up the good work.