GitLab 8.9 released(about.gitlab.com)
about.gitlab.com
GitLab 8.9 released
https://about.gitlab.com/2016/06/22/gitlab-8-9-released/
15 comments
Try again in a few months and it should be a lot better, lots of work has been going into improving performance across the board, e.g. this week we've had two pretty big changes: https://www.scribd.com/doc/316471059/GitLab-Infrastructure-2... and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4802 :)
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.
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.
Thanks for your kind words Nina. I'm glad you appreciate the openness, effort, education pricing and packaging.
The wiki is something we don't but enough effort in ourselves, it is not Gollum's fault. There are a lot of open issues for it https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sor...
We've been using static websites a lot ourselves instead of wiki's pages.gitlab.io
I would love for people to contribute wiki improvements. If you have questions on how to do this you can always ask Remy, our merge request coach.
I would like to promise more efforts from our side for the wiki but right now we don't have any plans, so I don't want to give false expectations.
The wiki is something we don't but enough effort in ourselves, it is not Gollum's fault. There are a lot of open issues for it https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sor...
We've been using static websites a lot ourselves instead of wiki's pages.gitlab.io
I would love for people to contribute wiki improvements. If you have questions on how to do this you can always ask Remy, our merge request coach.
I would like to promise more efforts from our side for the wiki but right now we don't have any plans, so I don't want to give false expectations.
> 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'll look into contributing, thanks for the link!
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'll look into contributing, thanks for the link!
I agree that wiki's have their place and a valuable. Just wanted to explain where our efforts have been. Thanks for looking into contributing https://about.gitlab.com/2016/06/16/fearless-contribution-a-...
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...
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...
>merge restriction as a feature
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]
[1] https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
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]
[1] https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
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.
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.
Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?
This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."
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.
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.
Thanks, good point. We're extending protected branches so all code will have to undergo a code review, see https://gitlab.com/gitlab-org/gitlab-ce/issues/18193
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
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
1Password TOTP https://blog.agilebits.com/2015/01/26/totp-for-1password-use... is great, we use it extensively at GitLab https://gitlab.com/gitlab-com/www-gitlab-com/commit/a2885089...
Thanks for your kind words. We indeed want to be the one-stop-shop from idea to production. For the complete scope see https://about.gitlab.com/direction/#scope
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
Isn't U2F a Chrome only feature at the moment?
Are you using that seriously already?
Are you using that seriously already?
Firefox added it ~3 weeks ago under a flag in Nightly, should be in stable a few months from now.
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.
Thanks! Glad you like the direction!
[deleted]
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).
The Raspberry Pi 2 package sometimes takes longer to build. But that doesn't explain that the previous minor version didn't ship. I created https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1366 to look into this.
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.
Isn't that what deploy keys are for? See: http://docs.gitlab.com/ce/ssh/README.html#deploy-keys
Deploy keys give read-only access to clone a repository, and they are associated directly with the repository.
Deploy keys give read-only access to clone a repository, and they are associated directly with the repository.
The CI token for a project allows the runner to fetch a repo with basic auth. Would that work?
+1
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...
It looks like its more intended for asset files like PSDs and more where Git conflict management isn't as helpful.
Exactly, it is for files that can't be merged because they are binary instead of text based.
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.
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.
Really interesting new features
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).
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
Thanks. It should be possible to have the code coverage in the slack message. Consider opening an issue or contributing the code.
The comments text area slowness sounds bad. I've hear people complaining about slowness in Firefox before. I'm not sure how to proceed.
Not a bad idea to wait a week after the official release, we expect to have at least one patch release in this timeframe.
The comments text area slowness sounds bad. I've hear people complaining about slowness in Firefox before. I'm not sure how to proceed.
Not a bad idea to wait a week after the official release, we expect to have at least one patch release in this timeframe.
https://gitlab.com/gitlab-org/gitlab-ce/issues/19011
https://gitlab.com/gitlab-org/gitlab-ce/issues/19010
here you are :)
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.
here you are :)
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.
Thanks for creating the issues!
And you're welcome for the apt-get upgrades, glad they are a good experience for you.
And you're welcome for the apt-get upgrades, glad they are a good experience for you.
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?
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:
registry['username'] = "registry" registry['group'] = "registry" user['username'] = "git" user['group'] = "git" postgresql['username'] = "gitlab-psql" redis['username'] = "gitlab-redis" web_server['username'] = 'gitlab-www' web_server['group'] = 'gitlab-www' mattermost['username'] = 'mattermost' mattermost['group'] = 'mattermost'
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.
registry['username'] = "registry" registry['group'] = "registry" user['username'] = "git" user['group'] = "git" postgresql['username'] = "gitlab-psql" redis['username'] = "gitlab-redis" web_server['username'] = 'gitlab-www' web_server['group'] = 'gitlab-www' mattermost['username'] = 'mattermost' mattermost['group'] = 'mattermost'
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:
https://gitlab.com/gitlab-com/support-forum/issues/548
https://gitlab.com/gitlab-com/support-forum/issues/548
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:
https://gitlab.com/gitlab-org/gitlab-ce/issues/19004
Other than that, I'm perfectly happy. I love the progress!
https://gitlab.com/gitlab-org/gitlab-ce/issues/19004
Other than that, I'm perfectly happy. I love the progress!
Glad to hear your upgrade was smooth. I see your issue was already labeled by our team, so I hope it will receive more attention soon.
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...
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.
Yay! Our importer will import not only your repo but also your issues, PR's and wiki.
Is there a .travis.yml -> .gitlab-ci.yml conversion tool in the work?
It's the only thing preventing me from switching to gitlab really
We're not working on that as far as I know. But you'll find the format pretty familiar. See http://docs.gitlab.com/ce/ci/quick_start/README.html and http://docs.gitlab.com/ce/ci/yaml/README.html
Keep up the good work.