Whether you work on code or media, work thousands of miles away from your organization's HQ, or work on a project with ten thousand issues, GitLab 8.9 will help you get stuff done faster.
With GitLab 8.9 you will be able to work better on complex projects together with file locking, priority labels and new workflow tools, like a custom notification level and the ability to restrict merging until the build passes. We're also continuing to improve GitLab's built-in continuous integration. You can now specify environments, have artifacts expire and quickly get started with templates.
This month's Most Valuable Person (MVP) is Rui Santos, for building the new feature that restricts merging until your build passes. It's a great feature that we're sure many people are going to use. Thanks Rui!
Since GitLab 8.8.0 we've had 1761 commits with 1947 files changed, see what has changed exactly, below.
When you're working on files that Git can't merge for you, working with multiple people on the same file can be a risk. Conflicts when merging the non-text file (which inevitably happens when two people work on the same file at the same time), are hard to overcome and will require a lot of manual work to resolve.
To work around this, we've added the ability to lock files in GitLab. File Locking prevents everyone, except you, from modifying a specific file or entire directory. It's also a good way of communicating to your collaborators that you are working on this file.
For example, you're working on a game. Many people are involved with building the complex levels. With file locking, you can lock the level you want to work on by clicking lock in the interface:
Your colleagues will see that you are working on this file. Except for you, no one else is able to push changes that modify this file.
Once you're done making changes and you've merged them, you can remove your lock in the same way as you've placed it.
Find a list of all locked files under repository:
File locking is available as a paid option for Enterprise Edition and for free on GitLab.com. We welcome further suggestions to expanding this feature.
Read more in the File lock documentation.
You can already deploy from GitLab to your various environments, whether it is test, staging or production. With GitLab CI you can set up pipelines with one or more jobs that deploy for you.
With GitLab 8.9 you can now define environments in your project's CI configuration file (
.gitlab-ci.yml). This allows you to track deployments to these environments and quickly understand things like "what's running in staging?"
Defining an environment is as simple as adding the
environment variable to your
deploy to production: stage: deploy script: git push production HEAD:master environment: production
You can then see exactly what is live on which environment:
Read more in the documentation on environments in GitLab CI.
It can be hard to prioritize issues and merge requests, especially larger projects can have a hard time sorting through hundreds, thousands of issues.
Adding priorities to issues could help with that, but we felt that there had to be a better way that involved less manual work. Our solution is prioritized labels.
Prioritized labels are like any other label, but sorted by priority. This allows you to sort issues and merge requests by priority. Those with the highest priority label, will appear on top.
For instance, the highest priority label for GitLab is
P1. If I sort by priority, I will see that issues with
P1 appear on top, followed by
P2, etc. In most cases,
security issues are very important. By making the
security label highly prioritized, I can rest assure that my colleagues will start working on those issues before any other issue in this milestone.
If you prefer a more traditional priority system, you're free to add labels such as
Right now, priority sorting is based the highest priority label only.
Read more in the documentation about Labels.
It's amazing to see how people use GitLab. Some people only review code, others closely monitor everything that happens on the issue tracker, yet other people only want to see what's new.
To make it easier to only get notified on what's important to you, we've added a new notification level: custom.
The custom notification level works just like a participating level. This means anywhere you participate or get mentioned, you receive a notification. On top of that, you now have the ability to also receive select notifications for things that are important to you.
So if you just want notifications for new merge requests, you can now easily set that up.
Read more in the documentation about Notifications.
Rather than having to contact the owners through some other means, you can now request access to a project straight from GitLab. Find the button on the project home page:
You'll get a notification when someone requests access and see the request appear in the members sections of your project.
Continuous integration, built into GitLab, works by a
.gitlab-ci.yml file, where you define your tests, builds and deployments. Getting started with creating this file can be hard, so we've created several templates to make this easier.
To start with a template
.gitlab-ci.yml, simply create a new file and call it
.gitlab-ci.yml. You'll see a dropdown appear where you can choose from several templates.
If you want to contribute your own templates, you can do so in the
Want to give GitLab CI a roll? You can use it completely for free on GitLab.com or on your own server.
We've revamped the navigation of GitLab. We wrote before about this, but have made further changes.
The main navigation within projects is now on the top bar. Global navigation, to pages specific to you, such as your issues and groups is in the new sidebar, hiding automatically.
GitLab now fully supports the Universal 2nd Factor (U2F) authentication standard. This means you can use a device like the U2F security keys by Yubico, known as YubiKeys as your 2nd factor when signing into GitLab.
If you're moving between GitLab instances or just want a backup of your most important data, you can now Import and Export entire projects.
Visit the project settings page to export your project. Importing a project can be done from the new project page.
Read more in the documentation.
You can already merge a merge request automatically after the CI builds have passed successfully. Thanks to Rui Santos, you can now even prevent people from merging a merge request unless the build is 'green'.
This prevents people from circumventing your tests, guards your code from sloppy contributions and encourages everyone to maintain a solid test suite.
GitLab Geo allows you to have one or multiple mirrored instance of GitLab running in another location. That allows your remote team to have quick cloning and pulling of repositories, while still having everyone, globally in sync.
We released Geo in Alpha with GitLab 8.5 and have been testing it intensely internally and with customers since. One customer reported that git clone times dropped from 10 minutes to 30 seconds on average for their teams.
GitLab Geo isn't supported for disaster recovery purposes yet. We've released a guide with manual steps in the unfortunate case that you'd have to use it for this purpose, but we recommend against using it for that.
GitLab Geo only supports PostgreSQL at the moment. MySQL is not supported.
To get started with GitLab Geo, read our documentation on it.
This release has more improvements, including security fixes. Please check out the Changelog to see the all named changes. See below for some further highlights of changes.
Besides issues and merge requests, you can now also vote on individual comments. Whether you want to react to someone without distorting the flow of the conversation or want to conduct a quick poll, you can now do it quickly, everywhere.
Read more in the award emoji documentation.
Every issue and merge request can now be marked as 'Todo' or 'Done'. This means you don't have to go back to the lists of Todos to mark one off and can even add items quickly to your Todos. Super useful!
Read more in the Todos documentation.
With label priorities and future features (such as issue boards), labels are becoming more and more important in GitLab. To make working with issues a bit easier, we've added the ability to bulk-assign labels.
If you're using artifacts in GitLab's built-in CI, you might be building up quite a catalogue of old data. You can now have artifacts expire by adding a
expire_in line to your
.gitlab-ci.yml file. The artifacts will expire after the duration that you specify.
job: artifacts: expire_in: 1 week
You can use natural language to set the expiry time:
Note: this feature requires Runner 1.3, released at the same time as GitLab 8.9
Read more in the artifacts documentation.
You can now only have artifacts be made available on failure, success or always.
job: artifacts: when: on_failure
The default behavior is the same as before, only creating artifacts on success.
Note: this feature requires Runner 1.3, released at the same time as GitLab 8.9
Read more in the artifacts documentation.
GitLab 8.9 adds support for Manifest V1 generated by older versions of Docker (before 1.10).
Shared Runners now prioritize projects without any other shared Runners assigned to them, before allocating more shared Runners to a single demanding project.
Mattermost 3.1 ships in GitLab 8.9 with multi-team accounts, Japanese language translation, Apple Watch & upgraded notifications, keyboard shortcuts & channel switcher, new full width and compact view display options, new emoji, plus security updates and many more improvements.
The upgrade requires manual steps! Before upgrading, make sure to read documentation for upgrades from versions prior to 8.9
If you run your own CA or you have self-signed certificates, you need to tell omnibus-gitlab explicitly to trust them. This is required for web-hooks, system-hooks and anything that requires a trusted connection. Accomplishing this task was possible with older versions of the package, however you had to repeat it at every upgrade. Now it is possible to add all your custom certificates into a single place and after reconfiguring the package, GitLab will be able to verify the certificate authenticity. For more information, see the custom SSL certificate documentation.
Performance is a great priority for us. We're working hard on making sure GitLab can handle the loads of very large instances (like GitLab.com with hundreds of thousands of active users) easily.
With GitLab 8.9 we've made many improvements, below are some of the highlights.
We increased the default memory limits from 300-350MB to 450-600MB per worker. Previously, our workers were being killed every 6 seconds. This was increasing the load of the whole system, as every 6 seconds a new worker was spawned that had to create new connections to the database and cache the data that is used often. As a result of this change we saw a drop in HTTP queuing time from ~2 seconds down to ~100ms on average. As a side effect we also noticed that the system load of our worker and database nodes went down to half. Memory usage on the workers does not change too much, but worker processes now live for 20 minutes on average.
See how this affected the worker load (for GitLab.com):
We've changed how we schedule mirroring in Sidekiq. See the difference in queries being pushed into the database:
This API endpoint allows you to retrieve some information about the current state of Sidekiq, its jobs, queues, and processes.
users.stateis now indexed
keys.fingerprintcolumn is now indexed and any duplicate keys are removed automatically. This speeds up looking up keys using a fingerprint
Downtime notice: while technically this release allows one to upgrade without downtime, one may get errors if new comments or award emoji are created/assigned during the upgrade.
Note: We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping. If you are upgrading from a GitLab version prior to 8.0 and you have CI enabled, you have to upgrade to GitLab 8.0 first.
Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a
If you are setting up a new GitLab installation please see the download GitLab page.
Check out our update page.
The mentioned EE only features and things like LDAP group support can be found in GitLab Enterprise Edition. For a complete overview please have a look at the feature list of GitLab EE.
Access to GitLab Enterprise Edition is included with a subscription. No time to upgrade GitLab yourself? A subscription also entitles you to our upgrade and installation services.