9.5

GitLab 9.5 Release

GitLab 9.5 released with GPG Commit Verification and Project Templates

GitLab 9.5 Released with GPG Commit Verification, Project Templates, Automatic Retry for Failed CI Jobs, Merge Request Diff File Navigation, great Performance Improvements, and much more!

Everything we do at GitLab, from our integrated product to our monthly releases, is centered on the goal of helping development teams reduce time to value. With each release, we want to help you do more in less time, while also providing an intuitive and user-friendly experience in our product. GitLab 9.5 takes a big step in furthering this goal. This release features improvements to our navigation, new project templates with pre-configured CI, and new automation features for CI and performance monitoring that will save you time and effort.

This will be the last 9.x release, as we're preparing to release GitLab 10.0 on September 22nd! Nonetheless, we're shipping some great new features to round off our 9.x releases:

To help improve your experience navigating GitLab, we've updated the new navigation, streamlining the UI and reducing the number of clicks it takes to move through your GitLab instance. With the newly added icons and subnav on hover, it's easier and faster than ever to explore GitLab.

Getting started on a new project just got faster. In GitLab 9.5, we've introduced Project Templates, which allow you to quickly create a new project that has CI pre-configured.

Continuing on our mission to save you time, we've made it possible for GitLab to automatically retry failed jobs ran with GitLab CI/CD. Now, you don't have to worry about losing time going back to your project's pipelines just to hit retry on a failed job. 🙌

GitLab 9.5 also brings improvements to the latter part of the development lifecycle. With the addition of Automatic Monitoring for Auto Deployed applications we've made it easier for you to collect response and system metrics from your apps.

And last but not least, we're shipping tons of performance improvements to continue to make GitLab faster than ever! 🚀 Enjoy!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Alexis Reigel

Alexis added support for verifying signed commits to GitLab! Now all commits that include a GPG signature will show their verification status next to the commit author.

It’s amazing and we all love it! Thanks Alexis! 🙌

9.5 Key improvements released in GitLab 9.5

GPG Commit Verification

GPG Commit Verification

When you commit a change in Git, you tell Git who the author is. This is not verified, meaning a bad actor could create a commit that looks like it was made by the original author.

GPG signed commits solves this problem by allowing you to sign your commits, proving that you’re the original author (because only you have the private key that matches the public key).

GitLab 9.5 now supports GPG signed commits. In your user Settings > GPG Keys you can upload your GPG public key. Signed commits will now show up as verified in GitLab (or unverified).

Thank you Alexis Reigel for this amazing contribution!

GPG Commit Verification

New Navigation Improvements

New Navigation Improvements

In GitLab 9.4 we introduced a preview of our new navigation to make GitLab easier to navigate.

We’d love to thank our community for the great feedback and in GitLab 9.5 we’ve introduced a number of improvements as a result of what we heard.

It’s now possible to collapse the left menu, freeing up more screen space. We’ve also added a new hovering sub-menu to improve navigation between menus, minimize clicks, and reduce page loads.

If you haven’t tried out the new navigation, click on your profile image in the top right corner and choose Turn on new navigation.

We still have a number of new improvements to make before switching over to the new navigation next month, in GitLab 10.0, and would love to hear more feedback to help us create a navigation experience that works for everyone.

New Navigation Improvements

Project Templates

Project Templates

Getting started with GitLab can be daunting. Learning all that GitLab has to offer is even more so. For these reasons, we added Project Templates to help you quickly create a new project from a template that already has some working example code and pre-configured CI.

In GitLab 9.5 we’re supporting some of the most common environments: Ruby on Rails, Node Express, and Java Spring.

Project Templates

Automatic Retry for Failed CI Jobs

Automatic Retry for Failed CI Jobs

Sometimes pipelines fail because one job encountered unexpected transient problems that are not directly related to the code, and often running the job again is enough to make it succeed after a few retries.

In order to automate this process, in GitLab 9.5 you can specify a retry keyword in your .gitlab-ci.yml file to make GitLab CI/CD retry a job for a specific number of times before marking it as failed.

Automatic Retry for Failed CI Jobs

Automatically Monitor Auto Deployed Apps

Automatically Monitor Auto Deployed Apps

As part of GitLab 9.4 we introduced Web Application Monitoring, enabling users to monitor their apps within GitLab for critical response metrics: throughput, latency, and error rate.

With the launch of GitLab 9.5, we have made it even easier to keep an eye on these important metrics for Auto Deployed apps. If you have deployed GitLab using our GitLab-Omnibus Helm chart, no configuration is required at all! For other installation methods, simply ensure NGINX ingress is monitored by Prometheus.

Automatically Monitor Auto Deployed Apps

9.5 Other improvements in GitLab 9.5

Postgres HA Automatic Failover (Beta)

Postgres HA Automatic Failover (Beta)

For organizations with a large number of developers, or simply because GitLab is an integral part of the software engineering process, it is important to ensure the scalability, performance, and reliability of the GitLab service.

In GitLab 9.4 we released Postgres High Availability with manual failover in beta, reducing the impact and time to recover from a database outage. In 9.5, we have continued to improve our support and now provide automatic failover of a database node. This means GitLab can transparently and without intervention recover from a database server outage without impacting a company’s SDLC process, reducing wake up calls and disruption to developers. We will continue to innovate on our high availability feature set in future releases.

CI_JOB_TOKEN Variable for Artifacts API

CI_JOB_TOKEN Variable for Artifacts API

With GitLab 9.3, we released features that allowed different projects to be connected through Multi-Project Pipelines. The introduction of these dependencies raised the need to access artifacts created by another related project in an easy way.

Now with GitLab 9.5 this can be done using the $CI_JOB_TOKEN variable, automatically available to any job, using the following syntax in .gitlab-ci.yml:

curl --header "JOB-TOKEN: $CI_JOB_TOKEN" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test"

Group-level Secret Variables API

Group-level Secret Variables API

In GitLab 9.4, we introduced Group-level Secret Variables, so you can define variables that apply to multiple projects in the same group. GitLab 9.5 adds management of these variables using API calls, allowing easy access and integration with third-party tools and scripts: with this feature you can list, show, create, update and remove group-level variables using a REST interface.

Enhanced Security Checks for Pipelines on Protected Branches

Enhanced Security Checks for Pipelines on Protected Branches

In order to allow only authorized people to modify what is released to the public, all of the interactions with pipelines run on protected branches (triggering pipelines manually, retry existing jobs, perform any manual action, etc) are now limited to users that have permissions to modify those branches.

Previously, the merge request (MR) source branch in the widget linked to the commits page. Now it links to the file repository page (of that branch). This small tweak is much more useful. You can now immediately explore the changes in the branch thus far, and make further commits from the file explorer UI itself. You can still easily access the commits of the source branch in the Commits tab of the merge request itself.

MR Widget Links to Repository

Group Milestones API

Group Milestones API

In this release, we’ve also added an API for Group Milestones. It allows you to create and edit milestones, as well as get all issues and merge requests associated with a milestone. This is similar to our existing project milestones API.

Streamline JIRA Integration

Streamline JIRA Integration

Previously, the JIRA integration configuration required you to enter a JIRA project key. This was unnecessarily confusing, since it implied that the integration was one GitLab project to one JIRA project. Instead, the integration has always been one GitLab project to one JIRA instance (and thus, all JIRA projects in that instance). We have removed the JIRA project key from the settings page to streamline this integration.

Streamline JIRA Integration

Pull Mirrored Repository over SSH

Pull Mirrored Repository over SSH

Repository mirroring is a great way to update all code, branches, tags and commits from an upstream repository.

In GitLab 9.5, you can now pull changes into your repositories using SSH, allowing Deploy Keys to be used with repository mirroring.

This addition to mirroring makes for a more secure way to connect your repositories and is great for automation as you won’t have any pesky issues if a password gets changed.

Return Resource URIs in API

Return Resource URIs in API

In GitLab 9.5 we’re taking a step towards improving our V4 API navigability.

We’re now returning related resources URIs as an addition to the requested resource data. It means that, instead of requiring you to build the URI to a related resource on the client-side, we provide these URIs directly in the API responses.

For now, projects and issues endpoints received the update, but we’re looking forward to introduce this information in other endpoints in the next releases.

GitLab Runner 9.5

GitLab Runner 9.5

We’re also releasing GitLab Runner 9.5 today!

Most interesting changes:

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

Technical Articles

Technical Articles

To make GitLab easier to onboard, use, and discover, we are constantly improving our documentation and publishing new technical articles with tutorials, guides, and technical overviews.

This month, we’re glad to announce two new great tutorials:

Merge Request Diff File Navigation

Merge Request Diff File Navigation

We’ve made it easier to navigate between different sections of the code diff quickly. In GitLab 9.5, we added a helpful dropdown that you can use to easily jump to different files in a merge request. This is especially useful for merge requests with a lot of files and a large number of changes.

Merge Request Diff File Navigation

Variables support for Pipelines triggered with CI_JOB_TOKEN

Variables support for Pipelines triggered with CI_JOB_TOKEN

Multi-Project Pipelines, introduced in GitLab 9.3, leverage the $CI_JOB_TOKEN variable to trigger pipelines in related projects, but passing variables to those triggers, as you can do with regular triggers, was not supported. GitLab 9.5 fills this gap and adds support for variables to pipeline triggers even if they’re invoked using $CI_JOB_TOKEN.

Confidential Issue Toggle

Confidential Issue Toggle

Toggling confidentiality on and off for issues now happens in the sidebar. In the next release, we also plan to push the “move issue” functionality to the sidebar as well. Together, this will free up the main area on the issue page to focus on editing the title and description.

Confidential Issue Toggle

Search Bar for Group Issues Page

Search Bar for Group Issues Page

We’ve taken the new filter search bar UI design for project issues and merge requests, and applied it to the group issues page. Now you can use the same powerful UI for finding and managing issues across multiple projects in a group.

Search Bar for Group Issues Page

Group Milestones Quick Action

Group Milestones Quick Action

In GitLab 9.4 we released Group Milestones, giving you a truly native way to manage issues together in a milestone that stretches across all projects in a single group. In this release we include the ability to assign a group milestone using a quick action and also include a system note to the thread when a group milestone is assigned or removed. This is the same behavior as that of project milestones.

Group Milestones Quick Action

New Issue Based on Pre-selected Project

New Issue Based on Pre-selected Project

Previously, you could create a new issue from the group issues page. But GitLab made you select a project as part of that flow. With this new change, GitLab remembers the previous project you selected, so you can skip that step the next time. This feature continues to make GitLab a team-based tool that focuses on groups. Sometimes you don’t care where an issue comes from. You just want to create an issue scoped to a group. Now you can do so quickly on the group issues page. And if you ever want to change your mind, you can always move an issue to another project after the fact.

New Issue Based on Pre-selected Project

“Remove Source Branch” Disabled by Default

“Remove Source Branch” Disabled by Default

Many users follow a Git workflow whereby they remove the source branch after a merge request has been merged. We have a useful feature to automate this process with a simple checkbox setting in the merge request widget. We’ve received overwhelming feedback that this setting should be disabled by default, since it is a destructive action. With this release, it is now disabled when you create a merge request. If you indeed do want to enable it, simply check the checkbox at any time before merging.

"Remove Source Branch" Disabled by Default

GitLab Mattermost 4.1

GitLab Mattermost 4.1

GitLab 9.5 includes Mattermost 4.1, an open source Slack-alternative whose newest release simplifies the securing of integrations with personal access tokens, and much more.

This version includes security updates and an upgrade is recommended.

GitLab Geo Improvements

GitLab Geo Improvements

Notable changes:

Omnibus Improvements

Omnibus Improvements

Deprecations Deprecations

PostgreSQL 9.2 Support

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 package. Due to this change, upgrading to GitLab 10.0 requires the Postgres database to already be running version 9.6.

If you are upgrading from at least GitLab 9.0, your database is already running verison 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.

TLSv1 no Longer Accepted by Default

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

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.

Drop Support of Legacy Git Storage Configuration

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.

GitLab CI API v1, GitLab Runner 1.11.x

GitLab CI API v1, GitLab Runner 1.11.x

In 9.0 we released a new version of GitLab Runner that is based on the new API v4 instead of the old CI API v1. We are still supporting the old version of the API in GitLab, so users that are still using GitLab Runners 1.11.x can take their time for the migration process. With GitLab 10.0, planned to be shipped on September 22nd, we are going to remove the old CI API from GitLab, making GitLab Runner 1.11.x unable to communicate with the system. If you are using old GitLab Runner (<9.0), or any tools that are using GitLab CI API v1, an upgrade will be required.

Planned removal date: September 22nd, 2017.

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Upgrade barometer Upgrade barometer

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

For this release we have migrations and post-deploy migrations.

GitLab.com migrations took approximately 25 minutes and post-deploy migrations amounted for a total of around 9 minutes.

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

Migration Of Event Logs

Starting with GitLab 9.5 we will be migrating the database tables used for storing event logs into a new format. This migration is performed to significantly reduce the amount of space required by the event log and to allow for much more efficient querying of the data. For GitLab.com we expect to reduce the table size by 80% and to make certain queries using this data up to 66 times faster.

This is a two-step process with the first step being performed in 9.5 and the second step being performed in 10.0. The first step in this process involves migrating the data from the old “events” table into a new table. This procedure is performed using background migrations and for very large instances (e.g. those the size of GitLab.com) the expected completion time is between 5 and 7 days. This time can be reduced by increasing the number of Sidekiq workers that can process the “background_migration” queue.

In 10.0 we will perform a cleanup procedure that does not require downtime if and only if you upgrade to 9.5 first and your GitLab instance meets the requirements for online upgrades as listed in “Upgrading Without Downtime”. You can not upgrade straight to 10.0 from an earlier version without downtime.

Because of these background migrations potentially taking a few days to complete we recommend users to keep at least 7 days between upgrading to 9.5 and 10.0 (once 10.0 is released). Doing so should prevent you from having to take your GitLab instance offline for hours to perform the mentioned cleanup procedure.

To summarise, to make this procedure as easy as possible users are advised to:

  1. Set up their GitLab instance according to “Upgrading Without Downtime”.
  2. Upgrade to 9.5.0 as soon as possible.
  3. Upgrade to 10.0 as soon as possible, but at least 7 days after upgrading to 9.5.0.

If you want to see the progress of the migration process you can do so by running the following snippet of Ruby code in a Rails console:

Sidekiq::Queue.new('background_migration').size

This will return the number of remaining background migration jobs (this may include jobs for other migrations). Once this returns 0 the migration process is complete.

Alternatively you can go to /admin/background_jobs of your GitLab instance (you will need to be logged in as an admin for this to work) and look at the queue size of the “background_migration” queue in the “Queues” tab.

For more information see the merge request “Use a separate table for storing push events”.

Migration of Merge Request Diffs and Commits

GitLab 9.5 contains a second background migration, which uses the same mechanism as described above for the event logs. This migration moves the diffs and commits stored on old merge requests from a serialised column in one table, to two separate tables. This does not lead to any immediate space savings, but will enable space savings in future, as well as new features. It also improves query performance when fetching pipelines for large merge requests.

This migration is also expected to complete within seven days. It will not have the same cleanup procedure as for the events migration in 10.0, but in a later 10.X release.

The merge request that introduced this change was merge request commits background migration.

Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

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

GitLab Subscription Plans 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 CC0

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source