Jun 22, 2018 - Marcia Ramos  

GitLab 11.0 released with Auto DevOps and License Management

GitLab 11.0 released with Auto DevOps Generally Available, License Management, SAML SSO for Groups, open source Squash and Merge, and much more!

Writing and delivering quality software poses many challenges. First, you must solve tough business problems and craft great code. But the challenges don't stop there. You have to ensure your code is fast, secure, and bug-free. You will need to build, integrate, test, secure, review, configure, and deploy your code. Creating and managing this pipeline is time consuming and complex.

Beyond making it easy to host and collaborate on public and private repositories, GitLab also simplifies the rest of the process by offering the whole delivery toolchain, built in. And now, it's not only built in, it's automated. Simply commit your code and Auto DevOps can do the rest. Auto DevOps is a pre-built, fully featured CI/CD pipeline that automates the entire delivery process. It is Generally Available and ready for prime time in GitLab 11.0.

Other key features we have released in GitLab 11.0 include License Management to automatically detect licenses of your project's dependencies; enhanced Security Testing of your code, containers, and dependencies; further Kubernetes integration features; an enhanced Web IDE; enhanced Epic and Roadmap views; Incremental Rollouts; and much more.

First, some more detail about these key features.

Auto DevOps covers the end-to-end lifecycle: Simply commit your code to GitLab, then Auto DevOps does the rest: building, testing, code quality scanning, security scanning, license scanning, packaging, performance testing, deploying, and monitoring your application.

“GitLab is a key part of our software-delivery processes and because of them, we’ve improved our delivery velocity by four times and made it immensely easier for our teams to collaborate,” said Chris Hill, head of systems engineering for infotainment at Jaguar Land Rover.

“We’re excited about Auto DevOps, because it will allow us to focus on writing code and business value. GitLab can then handle the rest; automatically building, testing, deploying, and even monitoring our application.”

License Management (software composition analysis): Software is often a complex amalgamation of code that includes external components (libraries, frameworks, and utilities). Each component typically includes specific license permissions and limitations, so you need to track and manage these dependencies for your application. GitLab 11.0 includes License Management (software composition analysis) built into the Merge Request so you can track and manage the included licenses.

Security: This month we continue to improve GitLab's built-in security capabilities so you can "shift security left" and catch vulnerabilities early via integrated Static and Dynamic Application Security Testing, along with Dependency and Container Scanning. Specifically, we’ve extended coverage of Static Analysis Security Testing (SAST) to include Scala and .Net. We’re also including more details in the SAST reports so you can get insight about specific issues right there.

Kubernetes: As part of our ongoing effort to improve the integration with Kubernetes and make it easy for you to manage and monitor Kubernetes from GitLab, there are several new features. Most notably, when you need to debug or check on a pod, you can review the Kubernetes pod logs directly from GitLab's deployment board.

GitLab Web IDE: The more work you can do directly from the IDE, the more productive you can be. Now, you are able to view your CI/CD pipelines from the IDE and get immediate feedback if a pipeline fails. Switching tasks can be disruptive, so the updated Web IDE makes it easy to quickly switch to the next merge request, to create, improve, or review without leaving the Web IDE. This way, you can stay in the flow of writing and reviewing code changes.

Navigate Epics / Roadmaps: When you want to visualize how Epics and Roadmaps flow over time, it can be helpful to change the time scale and zoom out. We’ve updated the Epic/Roadmap navigation interface to make it easier to see the big picture and make planning easier.

Join us for an upcoming event 11.0 Release Radar webcast

GitLab MVP badge

This month's Most Valuable Person (MVP) is Vitaliy 'blackst0ne' Klachkov

Vitaliy has contributed many times to GitLab, and has already been the release MVP a couple of times this year. For GitLab 11.0, he handled a large amount of technical debt by converting most of our remaining Spinach tests to RSpec and relentlessly working to fix GitLab for Rails 5. Also, once we decided to bring the Squash and Merge feature into GitLab Core and GitLab.com free, Vitaliy took on the issue and made it happen for this release. Here are all the improvements he submitted to GitLab 11.0.

Vitaliy, you rock! Thanks again! 🙌 You’ll receive a brand new swag pack soon!

Key improvements released in GitLab 11.0

Auto DevOps Generally Available

Originally introduced in beta in GitLab 10.0, Auto DevOps is now Generally Available (GA) in GitLab 11.0. Auto DevOps provides a complete workflow for your project with minimal configuration, efficiently taking your application from the build stage through the production and monitoring stage.

Auto DevOps brings DevOps best practices to your project by automatically configuring your build, test, Code Quality, Static and Dynamic Security Testing, Dependency Scanning, License Management, Container Scanning, Review Apps, Browser Performance Testing, deployment, and monitoring in a single application. It makes it easy for teams adopting DevOps to start with a complete, holistic pipeline.

Auto DevOps enables developers to focus on what matters most to the organization – shipping code that brings value to their customers.

Check out our revamped quick start guide.

Auto DevOps Generally Available

CI/CD pipeline status and job traces in the Web IDE

Continuous integration is an important step in shipping high-quality software, and you can now check the CI status of the current commit at a glance by checking the status bar at the bottom left of the Web IDE. Even better, you can view the status of each job and the logs for each job on the right. This makes it easy to fix a merge request with CI failures by opening the failed job side by side with the file you’re working on.

Previously, fixing failed tests involved opening multiple tabs and switching backwards and forwards. Now, all the information you need can be opened right in the Web IDE, and in the future you’ll be able to preview and test your changes before you commit them.

CI/CD pipeline status and job traces in the Web IDE

Switch between merge requests in the Web IDE

It’s common to end up working on multiple merge requests across multiple projects, and it now only takes one click to switch among your assigned and authored merge requests. Whether you are reviewing others’ merge requests, or trying to get your own over the line, the new merge request switcher allows you to spend more time coding and less time searching.

Switch between merge requests in the Web IDE

License Management

In modern software development, most applications rely on external components to implement specific functions, preventing the need to code everything from scratch every time. This is why third-party libraries are so common, and fetched directly by package management tools like RubyGems or npm. However, this approach requires you to ensure that the licenses for external components are compatible with your application, and that there is no conflict that could lead to legal issues.

In GitLab 11.0, we are proud to introduce License Management as part of our integrated development workflow. It automatically collects all the licenses used by your dependencies and displays new ones in the Merge Request widget before they land on your main default branch.

If you are using Auto DevOps, License Management is automatically enabled for your projects. Otherwise, you can manually enable it for your custom .gitlab-ci.yml definitions.

License Management

SAML single sign-on for Groups (Beta)

Being able to manage user credentials at scale is a must for large organizations. Centralizing users on a company-controlled identity provider is a common solution, and we have expanded our support for authentication based on Security Assertion Markup Language (SAML) by adding it to Groups.

Group owners are now able to configure an identity provider and provide a single sign-on (SSO) link to users. By authorizing them through the provided URL, groups can provide managed authentication when instance-wide SAML is either unfeasible or not specific enough for the group.

This is especially important for groups on GitLab.com, which can now configure identity providers for enterprise use.

SAML single sign-on for Groups (Beta)

New navigation themes

In the last major release, we unveiled GitLab’s new navigation. With GitLab 11.0, we think it’s a good time to introduce an additional set of new navigation themes! Five new user interface themes provide you with even more options to personalize your GitLab experience.

Besides a fresh red theme, each theme received an additional light counterpart, allowing you to make a bold color statement!

New navigation themes

Other improvements in GitLab 11.0

Squash and Merge in GitLab Core and GitLab.com Free

When working on a large feature, developers often push multiple commits to a work-in-progress branch, and after code review, there may be even more commits to address various code issues. Before merging that branch to master, many teams prefer to squash all the commits into a single one, ensuring a clean Git history, making it easier for folks in the future to review previous code changes.

Squashing is a Git feature and a developer can do it right before merging on their local machine, but with squash and merge available directly in the GitLab web UI, you can do it with just a single click. For example, a repo maintainer merging-in the code can now do the squash without asking the code contributor to do so, saving one extra round-trip communication step.

Squash and Merge, previously available in GitLab Starter, GitLab.com Bronze, and higher tiers, is now open source and available in GitLab Core and GitLab.com Free! Many users have said that all teams would benefit from this feature, and we are happy to bring it to everyone.

Thank you blackst0ne for your contribution!

Squash and Merge in GitLab Core and GitLab.com Free

Roadmap date ranges

Since epics can take on any start and end dates, we wanted to provide a simple way for users to quickly view the ones that are more relevant in a given time range.

With this release, we are introducing Roadmap date ranges. You can now quickly click Quarters, Months, or Weeks, and immediately, the roadmap will be refreshed, enabling you see your epics from different time perspectives. Teams who are focused on shipping features in the next few weeks can use one granularity, while executive leadership folks who want a high-level overview can use the longer time-period views.

Roadmap date ranges

Issue Board assignee lists

Issue boards are a great tool for managing and tracking workflows, as your issues progress through different stages in your lifecycle, with label lists representing those stages.

With this release, we are introducing assignee lists to issue boards. An assignee list shows issues that are assigned to a specific user. This provides a whole new way to use issue boards: to view and manage issue assignments for your team.

You can now configure a board to a scope that matches that of your team, and then add assignee lists representing team members. This gives you instant visibility into what issues your team is working on, whether you are a manager who wants an overview and status of the team’s overall responsibilities, or an individual contributor who wants to sync up with another team member’s assigned issues.

You can even add label lists and assignee lists to the same board.

Issue Board assignee lists

Issues and merge requests from subgroups in API

Subgroup support is also now consistent in the API when it comes to retrieving issues and merge requests. That is, if you query a particular group through the API for issues and merge requests, you will get results from projects that are immediate children of that group, and also all from projects of all subgroups nesting down further. This is analogous to viewing the same objects in the web UI’s group list views, which was introduced in recent prior releases.

Specify deployment strategy from Auto DevOps settings

While some applications may benefit from deploying every change into production immediately after it’s done, others may fare better by grouping those changes into a common environment for more thorough testing. Configuring different deployment strategies for different projects previously meant dealing with project-specific variables and then exercising them as needed.

Starting in GitLab 11.0, Auto DevOps makes specifying your deployment strategy a single-click event. When enabling Auto DevOps for a specific project, you will be able to specify whether your application gets automatically deployed to production or deployed automatically to staging and then manually to production. This single-click configuration will allow you to spend more time working on your apps and less time configuring their deployment.

Specify deployment strategy from Auto DevOps settings

Always-on approvals

Merge request approvals are a longstanding GitLab feature that allows teams to enforce code review (or any type of review) in a merge request, before unblocking it for merging.

Prior to this release, the feature had to be configured in the project settings. To simplify and streamline the feature, approvals are now always on for all projects in GitLab (in Starter, Bronze, or higher tiers). At the same time, however, we definitely do not want to slow down creating and merging code. So when a user creates a project, the required number of approvals is by default zero for the project (essentially, the feature is “off”). As the project grows, the user (and their team) can naturally adopt approvals by raising that required number as appropriate to their workflow needs.

Always-on approvals

Fetch cluster parameters from GKE

Creating Kubernetes clusters in GitLab has never been easier. With GitLab 11.0, the “project” and “zones” values are automatically fetched from your Google Kubernetes Engine (GKE) account and displayed as a list for easy selection. Previously, creating a cluster using our GKE integration meant having to manually enter this data.

Simple cluster creation will allow you to quickly stand up clusters from GitLab and quickly deploy your apps.

Fetch cluster parameters from GKE

LFS files included when importing a project

Git LFS helps to version large files with Git by storing them outside the repository and lazily downloading files at checkout rather than clone.

When importing a project from GitHub, Bitbucket Cloud, or using a Git URL, GitLab now imports LFS objects so that you have a complete copy of the repository including those LFS objects. Previously, LFS objects were excluded from imports.

SAST for .NET and Scala

As part of our effort to increase the availability of our security tools to the most common languages and frameworks, we have been continuously iterating on Static Application Security Testing (SAST).

In GitLab 11.0, we add support for two new languages, .NET and Scala. Users don’t need to change anything in their projects if they are already using Auto DevOps or the latest version of the sast job definition in their .gitlab-ci.yml file.

Easily deploy and integrate JupyterHub with GitLab

JupyterHub is a multi-user service for easily launching notebooks across a data science team. Jupyter notebooks provide a web-based interactive programming environment commonly used for data analysis, simulation, visualization, and machine learning.

GitLab 11.0 can now deploy JupyterHub to an integrated Kubernetes cluster with a single click, and it is automatically configured to use GitLab for seamless authentication. Additional options like HTTPS, group filtering, and custom notebooks will be added in future releases.

Easily deploy and integrate JupyterHub with GitLab

Combined system note for successive issue description updates

GitLab allows for powerful asynchronous collaboration and communication. With the ability to document ideas and have conversations in so many places, we encourage always maintaining a single source of truth in the description area of an issue or epic.

This means that descriptions are often updated, many times in succession over a few minutes, leading to multiple system notes that say that the description has been updated. With this release, we are smartly combining those system notes if they happen within a short period of time, cleaning up the visual clutter and making comments in GitLab just a little bit easier to navigate. We’ll be adding the same functionality to merge requests in the next release.

Combined system note for successive issue description updates

Master role renamed to Maintainer

At GitLab, we are striving to build an inclusive culture. And so even within GitLab the product, we’re seeking ways to reflect that.

We’ve decided to rename the Master role to the Maintainer role. It removes the negative connotations that may be associated with the term “Master,” and at the same time, “Maintainer” is easily understood. Every small step helps, and we hope to move forward at GitLab, and together as an industry.

Master role renamed to Maintainer

Consistent naming format in issues API scope attribute

We made a small change in the issues API scope attribute to bring it in line with our consistent format of using snake case. The scope attribute now uses the values of created_by_me and assigned_to_me. You should use this format starting in GitLab 11.0 instead of the previous kebab-case (hyphenated) equivalents.

Get GitLab Runner IP address via the API

In GitLab 10.6 we added the ability to see the IP address of a given GitLab Runner in the details view in the UI. This is very useful to better recognize, troubleshoot, and manage your infrastructure.

With GitLab 11.0, we also expose this information in the API response so that it can be used by automated processes.

Thank you Lars Greiss for your contribution!

Improved deprecated configuration detection

Starting from GitLab 11.0, the Omnibus GitLab package will check for deprecated configuration in gitlab.rb, prior to starting an upgrade. In the event deprecated configuration settings are found, the package will abort the upgrade process prior to any changes. This allows the existing version to continue to run, while an administrator updates the problematic settings.

Project-specific pipeline ID

When running CI/CD jobs for your project, sometimes you need a way to differentiate one execution from another. For this scope, you need a unique identifier that changes every time a new pipeline is created. This feature was already available through the CI_PIPELINE_ID environment variable, but this counter is unique for the entire GitLab instance and so it grows very fast, creating possible problems with long numbers.

In GitLab 11.0 we are introducing another environment variable, CI_PIPELINE_IID, that contains a reference that is specific to the project. It means that it is incremented only when another run for the same project is created, keeping the value low and allowing developers to use it as part of the release process, for example as part of the version number.

Open projects in Xcode

At WWDC earlier this month, Apple announced their Xcode integration with GitLab, which makes it easier to work with your Xcode projects hosted in GitLab.

Projects that contain a .xcodeproj or .xcworkspace file can now be cloned in Xcode using the new Open in Xcode button in GitLab. When viewing Xcode projects in the GitLab interface, the button will be available in GitLab next to the Git URL for cloning your project.

Open projects in Xcode

Unlimited Guests for free in Ultimate

In order to help customers get the most from their GitLab instances, Guest users no longer count against seat count for Ultimate licenses.

Since these users no longer consume seats (they’re effectively free to add), it gives more users in an organization the chance to join the instance and contribute to the conversation. You’re free to promote these users, but they’ll count against your license’s seat count once they’re promoted beyond Guest in any project or group.

This also means that if a user logs in and is never added to a project/group, they have no role applied, therefore they are considered as ‘Guests.’

Assign ancestor group milestones

GitLab supports subgroups, and we have now leveraged that subgrouping structure for milestones. For any issue or merge request, you can now assign it a project milestone or a group milestone inherited from any ancestor group.

In particular, you can now have a high-level group with a set of milestones at that level. You can then use those same milestones in any issues and merge requests in any subgroups deeper down, providing a powerful and flexible mechanism to organize work if you have nested groups and projects.

Furthermore, you can filter by this milestone in group issue lists and group issue boards, so that you can pull in targeted objects from different levels in customized views.

Assign ancestor group milestones

Persistent Auto DevOps deploy tokens for Kubernetes

Previously, when Auto DevOps was used for private or internal projects, the registry was not accessible by Kubernetes after the deploy job completed. This prevented the cluster from fetching the image again (for scaling, failures, etc).

With GitLab 11.0, a new deploy token is created to provide persistent access to the registry when Auto DevOps is enabled on private/internal projects. This will ensure that the cluster can perform necessary operations and reduce possible failures.

Variables defining deployment policy for canary environments

Oftentimes we’d like to roll out changes to a subset of users or servers to evaluate its impact before deploying across an entire environment. Previously, Auto DevOps users had to make the Auto DevOps template explicit and then define the desired behavior in order to achieve canary deployments.

Starting with GitLab 11.0, users are able to define their canary policy by making use of the CANARY_ENABLED environment variable without the need to customize the Auto DevOps template, enabling faster canary policy declaration.

Unmergeable merge request notifications and todos

Developers often work on multiple merge requests at a time, and it can be a challenge to keep track of them when many are open at once, awaiting collaborator reviews and feedback. Sometimes a merge request becomes unmergeable because of a conflict, perhaps caused by a change on the target branch. As a result, when you return to work on the merge request, you need to resolve the conflict.

With this release, GitLab can now send you a notification and even assign you a todo if your merge request becomes unmergeable. You’ll receive these as long as you are the author of the merge request, or have set it to be merged once the pipeline succeeds. This allows you to be proactive in fixing conflicts, or at least know what to expect when you revisit a merge request that you had worked on previously.

Note: We originally missed mentioning this feature when this blog post was first published. This section has been added as of August 3, 2018.

Unmergeable merge request notifications and todos

Disable Auto DevOps jobs with variables

When your application doesn’t precisely fit one or more Auto DevOps stages, such as unit testing, code quality, etc., it is ideal to customize the pipeline to run only the jobs you care about.

GitLab 11.0 now provides the ability to disable one or more Auto DevOps jobs through the use of environment variables. This allows you to take advantage of the power of Auto DevOps, even when your application doesn’t fit with one of its stages.

Operations tab

With the release of GitLab 11.0 we have added an Operations section in the navigation sidebar, making it quicker to access and easier to discover our operations features. In this release Environments and Kubernetes have been moved from CI/CD to Operations, and we will continue to add sections for features like Metrics and Logs in upcoming releases.

Operations tab

Cloud-native GitLab Helm chart now Beta

We are excited to announce that the cloud-native GitLab Helm chart is now in beta. This chart features a more cloud-native architecture, with a container for each component of GitLab and no requirement for shared storage. These changes result in increased resilience, scalability, and performance of GitLab on Kubernetes.

Expanded Issue Weight values

Issue weights in GitLab are useful for assigning effort estimation or any other cost metric associated with working on an issue. Previously, you could only assign values 1 through 9 for an issue. But this meant that teams that wanted more granularity in their weighting were constrained.

Starting in this release, issue weights can take on any non-negative integer value, from 0 upward, giving you unlimited flexibility in how you use weights. Furthermore, Burndown Charts automatically consider these new weight values, so your team can immediately make use of an expanded range.

Expanded Issue Weight values

View Kubernetes pod logs

A fundamental need for all developers is to be able to review logs in order to understand application behavior and troubleshoot any problems that arise. With GitLab 11.0, reviewing the logs of a troublesome pod is now just a click away.

On the Environments page, the status of pods for each application is displayed using Deploy Boards. Mousing over the pods will display the full pod name and status, and clicking on the pod will then display the logs.

View Kubernetes pod logs

Label lists redesign

Labels are a powerful mechanism in GitLab. As teams continue to create and use more labels, we want to ensure that managing them is easy. In this release, we’ve cleaned up the design of the label list pages, simplifying the interface, making it easier to consume information at a glance, and providing the UI affordances to quickly manage a particular label in further detail.

Label lists redesign

Regex support for variables expressions

In GitLab 10.7, we added support for variables expressions to only and except keywords. This allowed to define if a job should be created if a variable existed or had a specific value.

With GitLab 11.0, we are extending this syntax to allow regex. Now you can create more flexible definitions based on a fine-grained pattern matching against the value. For example, you can skip a job based on the commit message.

Regex support for variables expressions

GitLab Runner 11.0

We’re also releasing GitLab Runner 11.0 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Key changes in this release include:

The list of all changes can be found in GitLab Runner’s CHANGELOG.

Omnibus improvements

  • GitLab 11.0 includes Mattermost 4.10, an open source Slack-alternative whose newest release includes Environment Variables Support in GitLab Omnibus, faster load times, ability to convert channels to private, plus much more.
  • Added a new flag, master_on_initialization, to control if a database node should report it itself as master. This flag should be disabled on secondaries.
  • Prometheus rules can now be configured, providing the ability to add your own recording or alerting rules to the embedded Prometheus server.
  • The PgBouncer exporter has now been added, providing insight into its health and operation.
  • ruby has been updated to 2.4.4. git has been updated to 2.17.1. libpcre has been updated to 10.31. PgBouncer has been updated to 1.8.1.
  • Let’s Encrypt support has been added for the Registry and Mattermost. When new certificates are requested, these hostnames will be added to the certificate.


GitLab API v3

API v4 has been the preferred version of the GitLab API since 9.0. With GitLab 11.0, API v3 is removed and no longer supported. See the differences between API v3 and v4.

Planned removal date: June 22, 2018

PostgreSQL < 9.5 support

With GitLab 10.0, we removed PostgreSQL 9.2 support, as it became end of life. Going forward, GitLab requires PostgreSQL 9.5 or higher (MariaDB and MySQL support is available, but not recommended).

If you are using the Omnibus GitLab package, no action is required, as it has automatically updated the bundled PostgreSQL to 9.6.

Review our database documentation for more information.

Planned removal date: June 22, 2018

Support for DSA SSH keys

Due to published weakness in the ssh-dsa algorithm, we’ll wind down support for DSA SSH keys. In 11.0, the default value for the DSA SSH keys setting is “Are forbidden”. This setting is located in the visibility and access controls section of the Settings admin panel.

This setting may be overridden if desired. Beginning in 12.0, GitLab will always reject DSA SSH keys.

Planned removal date: June 22, 2018

Mattermost configuration changes

With the release of GitLab 11.0, the number of supported Mattermost configuration options in gitlab.rb has been reduced. We continue to support the core configuration settings necessary to run Mattermost, and set up the integration with GitLab. However other configuration settings now need to be set directly within the Mattermost Console, or via environment variables.

Previously with both Omnibus GitLab and Mattermost Console writing to the same configuration file, changes could be lost.

Learn more about configuring Mattermost in GitLab 11.0.

Planned removal date: June 22, 2018

Debian 7 Wheezy support

GitLab 11.0 is the last release with support for Debian 7 Wheezy.

Debian Wheezy will be officially end of life at the end of May 2018.

Planned removal date: June 22, 2018

Legacy Git storage configuration no longer supported

With the release of GitLab 9.0, we changed how to configure an alternate Git storage directory in order to support multiple directories. Backwards compatibility was maintained for the older formats to ease the upgrade process. With GitLab 11.0, we will no longer support the older configuration parameter, and users need to modify their gitlab.rb to support the current git_data_dirs format.

For example if your gitlab.rb contains git_data_dirs({ "default" => "/var/opt/gitlab/git-data" }) it should be changed to git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } }).

Planned removal date: June 22, 2018

Gemnasium project service

Gemnasium project service integration has been removed in GitLab 11.0 since Gemnasium ceased activities and the service is no longer available.

For more information, see our documentation about Gemnasium and importing to GitLab.

Planned removal date: June 22, 2018

GitLab Runner internal Prometheus exporter metrics names change

With GitLab Runner 11.0, we’ve changed the names of exported Prometheus metrics to make them more consistent with Prometheus community naming rules. Old metric names will be unavailable starting with this release.

Planned removal date: Jun 22, 2018

Dynamically generated milestone pages

GitLab currently offers both project milestones and group milestones. In particular, you can assign issues within projects of that group (and even within subgroups).

There is an existing feature in GitLab that allows you to pull in multiple project milestones with the same name, together in one page. In the past, this was created to solve some of the use cases of how group milestones work now. But since we now have group milestones as a first-class, native object, we no longer need this dynamically generated page. We will thus deprecate these dynamically generated milestone pages.

Planned removal date: August 22, 2018

Mattermost API v3 removed in Mattermost 5.0

On June 16, 2018, Mattermost 5.0 was released. In this version, Mattermost API v3 was removed, and only Mattermost API v4 is supported. GitLab 10.8 or lower integrates with Mattermost API v3. So if you are using GitLab 10.8 or lower currently, and upgrade your external Mattermost installation to 5.0, it will not work.

GitLab 11.0 integrates with Mattermost using Mattermost API v4. Mattermost API v4 is supported in Mattermost from 4.0 and up. So if you upgrade to GitLab 11.0, your external Mattermost installation will still work, provided it is version 4.0 or up.

Finally, none of this impacts you if you are using Mattermost bundled together in Omnibus. In GitLab 11.0, Mattermost 4.10 is bundled inside Omnibus.

Planned removal date: June 16, 2018

sast:container job and gl-sast-container-report.json artifact

Container Scanning was previously using sast:container for job name and gl-sast-container-report.json for the artifact name. While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release. You are advised to update your current .gitlab-ci.yml configuration with the current convention.

Planned removal date: GitLab 12.0

codeclimate job and codeclimate.json artifact

Code Quality was previously using codeclimate for job name and codeclimate.json for the artifact name. While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release. You are advised to update your current .gitlab-ci.yml configuration with the current convention.

Planned removal date: GitLab 12.0

GitLab Runner metrics_server configuration option

GitLab Runner can be configured to host a Prometheus exporter, that provides metrics about its internals. With GitLab Runner 11.0, the configuration setting that enables the exporter and defines listening address was renamed from metrics_server to listen_address. The old configuration option is deprecated and may be removed in the next major release.

Planned removal date: GitLab 12.0

Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation.

Upgrade barometer

In order to ensure successful upgrades to GitLab 11.0, the current version must be 10.8 or above. The GitLab 10.8 package includes additional checks for deprecated settings, and will abort the upgrade in the event any are found.

Previously it was possible to upgrade with settings that are no longer supported, causing the GitLab service to be unable to start.

You can upgrade to GitLab 11.0 from 10.8 or above without any downtime. See the documentation on downtimeless upgrades.

For this release, the upgrade process includes migrations and post-deploy migrations. When we upgraded our own GitLab.com instance, migrations took approximately 14 minutes and post-deploy migrations amounted to a total of around 12 minutes.

GitLab Geo users, please consult the documentation on upgrading Geo.

Raspberry Pi packages will be available starting with 11.0.2.


Please check out the changelog to see all the named changes:


If you are setting up a new GitLab installation please see the download GitLab page.


Check out our update page.


We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans
  • Free: Free-forever features for individual users
  • Premium: Enhance team productivity and coordination
  • Ultimate: Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under iStock license (purchased image)

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Open in Web IDE View source