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.

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.

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 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 .

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.

Join us for an upcoming event

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

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!).

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.

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

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.

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.

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.

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.

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 .

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.

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

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 .

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

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

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.

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!

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.

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.

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

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.

With this release we are proud to ship our most requested feature , GitLab’s Group-level 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.

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.

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

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 GitLab.com, an instance that hosts 1 million users!

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

At 12th September 2017 we’ve moved GitLab Runner to a new repository path. From now on Runner is available at https://gitlab.com/gitlab-org/gitlab-runner !

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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 .

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.

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

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).

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.

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

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.

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

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.

Deprecations

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.

Deprecation date: September 22nd, 2017.

API V3

In GitLab 8.17 we announced the deprecation of API v3.

We are still seeing a high volume of traffic on GitLab.com 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.

Deprecation 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.

Deprecation 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 .

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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" } }) .

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation date: March 22nd, 2018.

Runner's exec and service-related commands

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.

Deprecation date: March 22nd, 2018.