Sep 22, 2017 - Mike Bartlett  

GitLab 10.0 released with Auto DevOps and Group Issue Boards

GitLab 10.0 Released with Auto DevOps,Group Issue Boards, New Navigation, and much more!

From the formulation of an idea to executing and monitoring it in production, DevOps establishes a culture and environment where developing, testing, and releasing software can happen quickly, frequently, and more reliably.

GitLab 10.0 delivers a hands-free DevOps environment with the introduction of Auto DevOps, allowing your team to easily configure and adopt modern development practices in your workflow. Not only that, there's new navigation and a new way of collaborating across groups.

With every monthly release of GitLab, we introduce new capabilities and improve our existing features. GitLab 10.0 is no exception and includes numerous new additions, such as the ability to automatically resolve outdated merge request discussions, improvements to subgroups, and an API for Wiki thanks to a contribution from our open source community.

GitLab's powerful issue management capabilities keep getting better with every release. Filtering and searching issues across groups has been vastly improved, our updated UX makes moving issues easier to discover and can be automated through quick action commands. GitLab Enterprise Edition Premium customers using JIRA can now see commits and branches in JIRA's development panel.

Security and performance continues to improve. Administrators can now restrict SSH access through technology and key length. LDAP Group Sync can be automated through our API and can now lock down External Users at point of login as well. Performance continues to get faster, improving page loading speeds, the speed of creating projects and performing commits, and reduced memory usage.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Hiroyuki Sato

Once again, we’ve had an incredible number of contributions from the community, illustrating the power of open source software and its benefit to GitLab and all of our users and customers.

Hiroyuki has provided numerous contributions in GitLab 10.0, including performance improvements, enhancing searching and filtering issues and merge requests, as well as one of our favorite features of being able to filter issues by your own reactions so you can see what you’ve liked (or not!).

Thank you to everyone for your contributions, and a special thank you to Hiroyuki for such amazing work.

Key improvements released in GitLab 10.0

Auto DevOps

Auto DevOps brings DevOps best practices to your project by automatically configuring your build, test, code quality assurance, review apps, deployment, and monitoring in a single environment. In GitLab 10.0, we have introduced out-of-the-box templates to quickly set up an end-to-end DevOps lifecycle, built on top of GitLab CI/CD.

As it stands, GitLab offers a single environment where a code change can not only initiate a build, but deploy a Review App to preview your changes from within each merge request. During the review process GitLab’s recently introduced ability to measure Code Quality ensures changes improve the overall quality of your software.

After code review, GitLab’s deployment capabilities easily allow you to deploy to canary or production environments, as well as using GitLab Auto Deploy to deploy straight to Google Cloud. Post-deployment metrics with GitLab Auto Monitoring provide response and system metrics to make sure newly deployed code is performant.

Now, GitLab 10.0 brings this entire lifecycle together in an automated way, allowing you to go from idea to production in the blink of an eye with GitLab Auto Devops.

Auto DevOps automatically detects, builds, tests, deploys, and monitors applications. Leveraging Herokuish, it supports all languages and frameworks available through Heroku buildpacks, such as Ruby, Rails, Node, PHP, Python, and Java, as well as the ability to customize your own buildpacks. Read the quick start guide to begin right now.

Auto DevOps is currently in Beta and is not recommended for production use just yet.

Note: GitLab is not affiliated with Heroku or Glider Labs.

Group Issue Boards

Many teams work as a GitLab group, with work spanning many projects in that group. For example, many organizations are moving toward or have already adopted a microservices architecture where each microservice is one code repository (housed in one GitLab project). This means a team may naturally be working across multiple projects, making it extremely helpful to manage issues across all those projects together.

With this release we are proud to ship our most requested feature, GitLab’s Group-level Issue Boards!

Now you can manage all issues across all projects within a group single and concentrated view. Lists, labels, and milestones are all managed at the group level, allowing you to focus on the group.

Group Issue Boards

New User Experience

In GitLab 10.0 we are excited to unveil our new user experience, making it much easier to navigate GitLab!

For the last few months, we have been testing out a new way to navigate through GitLab. Based on feedback and user testing, we found that people had a few problems with the existing navigation. Understanding exactly which group or project you were currently viewing was often not obvious, switching between different areas of GitLab was cumbersome and there were a lot of inconsistencies with spacing and hierarchy that caused confusion.

GitLab 10.0 introduces a more consistent navigation experience. The colored top bar represents all global and personal aspects of GitLab – your groups, projects, issues, merge requests, todos and personal information. The new left navigation is contextual to the group or project you are viewing and also allows quicker navigation between areas of the project, with pull-out menus saving you clicks and page loads.

As an additional bonus, we’ve also brought back the ability to personalize your experience, allowing you to change the color theme of GitLab because, well, not everyone loves purple like we do!

New User Experience

Protected GitLab Runners

When running sensitive jobs in CI/CD pipelines, for example deployments to production environments, you want to be sure that nobody can access credential information or private configuration options. In order to avoid any data leakage, you can set the protected flag for a specific GitLab Runner, so only jobs running on protected branches are picked up.

Combining this feature with mandatory approval and Runner selection by tags, you can guarantee that only trusted code is executed on the Protected Runner.

Protected GitLab Runners

Object Storage for Git LFS

Git LFS provides a great way to efficiently store large files in Git.

Large files have a habit of using a lot of disk space and managing very large storage clusters can become painful as usage grows.

GitLab Enterprise Edition Premium now offers the ability to store LFS files in an object storage system such as the open source Minio or Amazon’s S3.

Object Storage for Git LFS

SSH Key Length Restrictions

With thanks to our community contributor Corey Hinshaw GitLab 10.0 now allows administrators to add restrictions on SSH keys.

This functionality allows administrators to restrict not only the type of SSH keys that may be used, but also the minimal key length, giving you a more secure way to manage your GitLab SSH access environment.

SSH Key Length Restrictions

Other improvements in GitLab 10.0

API Support for Wikis

You can now use the GitLab API to work with wiki pages! With the additions to the API, it is possible to get a list of all wiki pages, get a particular page, create a new wiki page, as well as edit and delete pages, providing a great way to programmatically access GitLab’s wiki functionality.

Many thanks to our community contributor, Vitaliy Klachkov for adding this functionality.

GitLab Runner 10.0

We’re also releasing GitLab Runner 10.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.

Most interesting changes:

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

GitLab Runner Locked to Project by Default

During the initial registration of a new GitLab Runner, you are asked if you want to lock it to the project for which you are providing the token. Before GitLab 10.0, the default choice was false, but it was not clear that this allows any Master of the project to enable the Runner also for other projects, and this might be a security risk. With GitLab 10.0, the default choice is now true, so the Runner cannot be easily assigned to other projects.

This behavior can be changed later in the Runner settings, if there is the need. It can be also set during registration manually (for interactive mode) or with the --locked=false option (for non-interactive mode).

Simplified Project Permissions

One of GitLab’s many distinguishing features is the granularity of permissions and access to project capabilities.

In GitLab 10.0 we have simplified the user interface, allowing you to maintain precise control of your project visibility, features and permissions, but doing so in an easy-to-use and beautiful interface.

Simplified Project Permissions

Improved Subgroup Permissions

In GitLab 9.0 we released subgroups, giving you more flexibility in how you organize projects and groups inside of GitLab. If you haven’t tried them out before, you can find out more about subgroups in our documentation.

We’ve now added the ability to allow owners to create subgroups if group creation has been restricted, making it easier for delegated users to manage the group structure of GitLab.

Access GitLab Commits and Branches in JIRA Development Panel

Many GitLab users are also JIRA users. With this release, we are significantly improving our JIRA integration by introducing linked commits and branches in a JIRA issue’s development panel. As you are interacting with a JIRA issue, you can now quickly click through to associated GitLab commits or branches, further tightening the GitLab-JIRA integration.

Access GitLab Commits and Branches in JIRA Development Panel

Time Tracking for Issues CSV Export

We have now included time tracking information (time estimate and time spent) in the existing issues CSV export functionality. This allows roles such as team leads or managers to manage time tracking information easily in issues using spreadsheets.

Thank you Bohdan V. for the contribution.

Time Tracking for Issues CSV Export

Filter by Reactions

Throughout GitLab, when you are filtering issues and merge requests, you can now filter by reactions you have added. You can use this as a generalized bookmarking feature. Just react to issues and merge requests by awarding different emoji, and now you access those objects quickly by filtering on them.

Thank you Hiroyuki Sato for the contribution.

Filter by Reactions

Move Issue Quick Action

There is now a move issue quick action to speed up your workflows even more. So you can now type comments, and perform yet another action (moving an issue), all within the comment box itself.

Thank you Manolis for the contribution.

Move Issue Quick Action

Redesigned System Notes Icons

As part of our continuing effort to define and distinguish our unique GitLab personality, we now have a redesigned set of system note icons.

Redesigned System Notes Icons

Improved Monitoring Dashboard

The environment monitoring dashboard has been significantly improved, with an improved look and feel as well as support for multiple series in a single chart. This provides a deeper-level insight into performance as well as easy comparisons. For example, an application’s throughput can now be broken out by HTTP response type, providing a single chart for both successful and failed request rates, as well as potential missing pages.

Improved Monitoring Dashboard

LDAP Group Sync API

GitLab’s LDAP Group Sync is now available via API, allowing you to programmatically request a sync event. This means that any group automation such as creation of groups performed via the API can immediately be programmatically synchronized to LDAP with one simple API call.

LDAP Config “verify_certificates” Defaults to Secure

The LDAP config option verify_certificates now defaults to true for security. This option was added in 9.4.2 but defaulted to false for backwards-compatibility.

Installations that are using start_tls or simple_tls for the encryption parameter and that unknowingly do not have SSL configured properly between the LDAP server and the GitLab server, may break if the LDAP server’s SSL certificate cannot be verified by the GitLab server.

Streamlined Omnibus GitLab Installation

Installation of GitLab is now easier and faster than ever! GitLab 10 adds support for specifying the GitLab URL directly when installing the package. When specified, GitLab will automatically be reconfigured with the URL and started, removing two steps from the installation process.

Omnibus Improvements

GitLab Mattermost 4.2

GitLab 10.0 includes Mattermost 4.2, an open source Slack-alternative whose newest release includes interactive message buttons to simplify complex workflows, plus much more.

This version includes security updates and an upgrade is recommended.

Weekly View for Cycle Analytics

Cycle Analytics measures the time it takes to go from an idea to production for each project you have. This is achieved not only by indicating the total time it takes to reach that point, but the total time is broken down into the multiple stages an idea has to pass through to be shipped.

With thanks to our community contributor, Mehdi Lahmam it is now possible to view your cycle over a seven-day period which is great for teams with very short release cycles.

Weekly View for Cycle Analytics

New GitLab Runner Repository

At 12th September 2017 we’ve moved GitLab Runner to a new repository path. From now on Runner is available at!

Please update your bookmarks!

New Predefined Variables for User Identity

When running pipelines, we have a lot of environment variables that are automatically set by GitLab, giving your scripts the ability to access important information. Starting with GitLab 10.0, two new variables, GITLAB_USER_NAME and GITLAB_USER_LOGIN, are now available to access the full name and the login username associated to the account that is running the job.

Variables for Pipeline Schedules API

In GitLab 9.2 we introduced Pipeline Schedules, and in the following release we added API and variables support. In GitLab 10.0, we complete the cycle adding variables support also to API calls. Now automatic interaction with Pipeline Schedules by third-party applications can benefit of more flexibility.

Share Locking Support for Subgroups

GitLab provides the ability to share projects between different groups, giving you even more flexibility with project structure and permissions.

Share locking provides the ability to restrict projects in particular groups from being shared, to enforce centralized security and policy.

Share locking has now been extended to subgroups, allowing subgroups to either inherit or override share locking from the parent group, giving more granular control over how projects can be distributed.

Dedicated Page for Service Desk Issues

Previously, managing Service Desk issues required searching for issues authored by the Support Bot on a project’s issue page. We now have a dedicated page accessible in the navigation that does that for you automatically. We also display the support email address itself on the page, allowing you to share it easily with anyone who you want to send in support requests with Service Desk.

Dedicated Page for Service Desk Issues

Group Merge Requests Search and Filter Bar

We have updated the group merge requests list page with the latest search and filter bar UI. This allows you to narrow down the merge requests you care about quickly, by author, assignee, milestone, label, or weight, similarly to what you’ve been able to do for a few releases now on the issue side.

Thank you Hiroyuki Sato for the contribution.

Group Merge Requests Search and Filter Bar

Move Issues from the Sidebar

The move issue functionality is now in the issue sidebar. This groups other useful actions outside the main issue area, which is now focused on the title and description only.

Move Issues from the Sidebar

Merge Request Inherits Issue Milestone and Labels

If you are using milestones and labels for your merge requests, you may often be copying these objects from the issue to an associated merge request. Now when you create a merge request from within an issue using the dedicated button, the milestone and labels are automatically inherited into the merge request.

Thank you haseeb for the contribution.

Merge Request Inherits Issue Milestone and Labels

Automatically Resolve Outdated MR Discussions

For some users, resolving a merge request diff discussion means simply pushing new code to replace the code in question. We’ve introduced a merge request setting to achieve exactly that. If the setting is on, any diff discussions will be resolved if a push makes that diff section outdated. Note that discussions on lines that don’t change and top-level resolvable discussions are not automatically resolved.

Thank you Ashley Dumaine for the contribution.

Automatically Resolve Outdated MR Discussions

LDAP Group Sync Improvements for External Users

LDAP Group Sync is available in GitLab Enterprise Edition and provides a great hassle-free way to manage user permissions by leveraging your existing LDAP group system and permissions.

GitLab further supports external users allowing more restrictive control on projects on a case-by-case basis.

In GitLab 10.0 synchronizing external user permissions will happen at login, in addition to the existing periodic synchronization. This means that any changes to permissions in your LDAP system can be immediately available to the user after logging in and denying access to unauthorized projects.

New Filter for Archived Projects

With thanks (again!) to our community contributor Mehdi Lahmam it is now possible to filter the project view to show archived projects only.

This may be useful when managing projects to see a distinct list of all archived projects and allow for easy deletion of archived projects by administrators.

New Filter for Archived Projects

Internationalized Project Activity Page

As part of our ongoing effort to translate GitLab into new languages, the Project Activity Page has now been made ready for translating.

We have recently created a Translation Community on CrowdIn making it easy for anyone to help translate pages on GitLab. If you wanted to get involved, please feel free to sign up through the community.

GitLab Geo Improvements

Notable changes shipped with GitLab 10.0:

  • GitLab Geo has fully removed the use of system hooks. If you upgrade to GitLab 10.0, you MUST enable SSH key lookups via the database. We highly recommend Geo installations either upgrade to CentOS 7.4 or use Ubuntu 16.04 to get the required OpenSSH version.
  • We improved the Geo download scheduler to skip over projects that recently failed.
  • We added improvements to the admin page for monitoring the database replication lag and log cursor state under an “Advanced” toggle (see screenshot below).
  • See the full list of changes here.
GitLab Geo Improvements

Performance Improvements

With every release we aim to make GitLab faster, more available, and more stable. We’re committed not only to making individual instances of GitLab even faster, but also to greatly improving the performance of, an instance that hosts 1 million users!

In GitLab 10.0 we have doubled down on this commitment and addressed more performance issues than any other previous release.

We are addressing high memory usage issues, making numerous pages a lot faster as well as improving the speed of creating projects and performing commits.


PostgreSQL 9.2 Support

With the release of GitLab 10.0 on September 22nd, support for Postgres 9.2 will end and it will be removed from the Omnibus GitLab package. For deployments using packaged Postgres, upgrading to GitLab 10.0 requires the database to already be running version 9.6.

If you are upgrading from at least GitLab 9.0, your database is already running version 9.6. If you are running a version older than 9.0, please upgrade your database to prepare for GitLab 10.

PostgreSQL 9.2 is end of life in September, five years after it was first released.

Planned removal date: September 22nd, 2017.


In GitLab 8.17 we announced the deprecation of API v3.

We are still seeing a high volume of traffic on using API v3 requests.

API v3 will be removed in GitLab 11 and we just wanted to ensure that developers were migrating to API v4. Please refer to our documentation that shows changes between the two API versions.

Planned removal date: GitLab 11.0

Koding Integration

The GitLab Koding integration is being removed as we continue to enhance GitLab’s in-line editing capabilities.

From GitLab 10.0 it will no longer be possible to activate Koding integration. Existing installations that are currently using Koding may continue to do so until GitLab 11.0 when this functionality will be completely removed.

Planned removal date: GitLab 11.0

TLSv1 no Longer Accepted by Default

GitLab 10 will no longer accept TLSv1 by default. If you would like to continue to accept TLSv1 connections, it can be added back to the list of supported protocols by editing the nginx['ssl_protocols'] field in gitlab.rb.

Planned removal date: September 22nd, 2017.

GitLab Git HTTP Server Configuration Support Removed

Since GitLab 8.2, we have used gitlab-workhorse to process Git HTTP traffic. Earlier versions of GitLab used gitlab-git-http-server, and configuration entries for it have been ignored. With GitLab 10, we will be removing the code to recognize the long-deprecated configuration parameters for gitlab-git-http-server. In the event your gitlab.rb configuration file contains these entries, they should be removed or GitLab configuration will fail.

Planned removal date: September 22nd, 2017.

Private Tokens

Private tokens allow a mechanism to access the API with a token unique to your user account.

Personal Access Tokens provide more granular access to GitLab via the API and are recommended over using Private Tokens.

Private Token support will be removed in GitLab 10.2 as we feel they are less secure that Personal Access Tokens.

Planned removal date: September 22nd, 2017.

LDAP Config “verify_certificates” Defaults to Secure

The LDAP config option verify_certificates now defaults to true for security. This option was added in 9.4.2 but defaulted to false for backwards-compatibility.

Installations that are using start_tls or simple_tls for the encryption parameter and that unknowingly do not have SSL configured properly between the LDAP server and the GitLab server, may break if the LDAP server’s SSL certificate cannot be verified by the GitLab server.

Planned removal date: September 22nd, 2017.

Custom SSH Client Configuration for the Git User

Currently, the Git user on a GitLab server can have custom SSH client configuration placed into ~git/.ssh/config .id_rsa and other configuration files are also picked up automatically.

This custom manual configuration is automatically picked up and used in a number of places. However, it’s insecure as there are no per-gitlab-user access controls on use of the key.

Planned removal date: September 22nd, 2018.

Drop Support of Legacy Git Storage Configuration

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. In a future release of GitLab, we will no longer support the older configuration parameter, and users should 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: March 22nd, 2018.

Keyword ‘types’ in ‘.gitlab-ci.yml’

The types keyword, that has been replaced by stages long time ago, is deprecated and will be removed in a future release of GitLab.

Planned removal date: March 22nd, 2018.

Build Badges

Old badges paths for builds are now deprecated in favor of pipeline badges, and will be removed in a future release of GitLab.

Planned removal date: March 22nd, 2018.

Auto Deploy

Auto Deploy is now part of Auto DevOps, and no longer needs to have standalone templates. With the incorporation in Auto DevOps, it has been improved with Helm Charts support and persistent database instances, to make deployments even more usable for production.

Planned removal date: November 22nd, 2017.

Legacy Triggers

Triggers with the legacy label do not have an associated user and only have access to the current project. You are advised to take ownership of any legacy triggers.

Planned removal date: January 22nd, 2018.

Code Quality ‘codeclimate’ Job Name

In the first iteration of GitLab Code Quality, we hardcoded detection of the job by codeclimate. We now officially look for codequality jobs, even if the old codeclimate is still working.

Planned removal date: March 22nd, 2018.

Runner’s ‘docker-ssh’ and ‘docker-ssh+machine’ executors

Two GitLab Runner’s executors – docker-ssh and docker-ssh+machine – are now deprecated. They will be removed in one of the upcoming releases.

You can read more about the decision in the issue.

Planned removal date: March 22nd, 2018.

We’re also deprecating all service-management-related commands (stop, start, restart, status, install, uninstall). They will be removed in one of the upcoming releases.

You can read more about the decision in the issue.

Planned removal date: March 22nd, 2018.

Removals and breaking changes

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

Upgrade barometer

To upgrade to GitLab 10.0 from the latest 9.5 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

If you are upgrading from a version prior to 9.5, migrations will take a significant amount of time based on the size of your database. For example on, the set of migrations would take over 24 hours. For larger deployments, we recommend upgrading to 9.5 first and allowing background migrations to run. Once completed, then continue and upgrade to GitLab 10.0.

You can check the status of background migrations by running this command from the Rails console:'background_migration').size

For this release we have migrations and post-deploy migrations. migrations took approximately five minutes and post-deploy migrations amounted for a total of around 15 minutes.

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


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 CC 2.0

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