Aug 22, 2017 - Marcia Ramos    
9.5

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

This month's Most Valuable Person ( MVP ) is 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! 🙌

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

Learn how you can associate your GPG signed commits with Git and GitLab


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.

Learn more about the Navigation Redesign

New Navigation Improvements

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.

Read through the documentation on Project Templates

Project Templates

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.

Read through the documentation on Automatic Retry for Failed CI Jobs

Automatic Retry for Failed CI Jobs

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.

Read through the documentation on monitoring Auto Deployed apps

Automatically Monitor Auto Deployed Apps

Other Improvements in GitLab 9.5

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.

Read through the documentation on Postgres HA

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"

Read more about using CI_JOB_TOKEN to download artifacts

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.

Read through the documentation on Group-level Secret Variables API

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.

Read more about GitLab CI/CD security model

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

Read through the documentation on Merge Requests

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.

Read through the documentation on Group Milestones API

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

Read through the documentation on JIRA Integration

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.

Read through the documentation on SSH authentication for Repository Mirroring

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.

Read through the documentation on Projects API

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.

Read through the documentation on GitLab Runner

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:

Would you like to contribute as well? Please do! Check our Community Writers Program to get started! :)

Read through our Technical Articles

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

Read through the documentation on merge requests

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.

Read more about passing variables in pipeline triggers

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

Read through the documentation on Confidential Issues

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

Read through the documentation on Searching through GitLab

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

Read through the documentation on Quick Actions

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

Read through the documentation on creating new issues

"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

Read through the documentation on Merge Requests

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.

Read through the documentation on GitLab Mattermost

GitLab Geo Improvements

Notable changes:

Read through the documentation on GitLab Geo

Omnibus Improvements

Read through the documentation on Omnibus GitLab

Performance Improvements

General Improvements

GitLab 9.5 includes numerous performance improvements including faster display of projects and issues and improved caching.

Most noticeable will be the improvements we’ve made to the front-end rendering through lazy image loading and deferred JavaScript loading, making pages render up to 50% faster as you can see in the image below.

fe_performance

Faster Pages

Faster Issues Pages: In GitLab 9.5 we improved the response timings when viewing project issue pages. We also improved response timings when sorting these issues by the creation time, update time or due date. For GitLab.com these changes resulted in issues pages loading roughly 2 times faster.

Faster Project Exploration Page: The “Explore Projects” page has been made faster by adjusting the pagination system. For GitLab.com this change reduces loading times by up to 2 seconds.

Faster Project Homepages: Loading times of project homepages have been improved as well. This has been improved by applying various changes such as caching the number of forks, removing redundant SQL queries and caching the number of personal projects per user.

Faster New Project pages: The time taken to create a new project in GitLab has been reduced as well. On GitLab.com, some projects could take over a minute to be created. This has now been reduced to under ten seconds, and further improvements are expected in GitLab 10.0.

transaction times for creating new projects in GitLab.com

Caching of GitLab Appearance and Broadcast Messages

GitLab stores appearance related configuration (e.g. the title) of an instance in a table called “appearances”. There is also a table used for storing broadcast messages. Previously these tables were queried on every single page. Starting with GitLab 9.5 we cache the appearances data and broadcast messages and refresh this whenever necessary.

Faster Event Feeds

The loading times of global, project, and group activity feeds have been improved significantly. For example, on GitLab.com the response timings of the “Activity” dashboard (showing the events of all projects you have access to) were reduced from a 99th percentile of 8-9 seconds to a 99th percentile of roughly 1.2 seconds. This can be seen in the following graph:

Event Loading Times

Using a logarithmic scale (base 2) we can more clearly see the impact of these improvements:

Event Loading Times Log Scale

These improvements are only available for users running PostgreSQL 9.3 or newer, users using an older version of PostgreSQL or MySQL will not benefit from these improvements.

PostgreSQL Idle Transaction Timeout

GitLab 9.5 adds support for a setting introduced in PostgreSQL 9.6: idle_in_transaction_session_timeout. This setting can be used to set a timeout for “idle in transaction” transactions. This setting is set to 60 seconds by default but can be changed like any other setting if desired.

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

Due: September 22nd, 2017.

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.

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

Due: September 22nd, 2017.

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

Due: March 22nd, 2018.

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.

Due: September 22nd, 2017.

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

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

Installing

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

Updating

Check out our update page.

GitLab Products

We offer four different products for you and your company:

  • GitLab Community Edition (CE): Open source, self-hosted solution of GitLab. Ideal for personal projects or small teams with minimal user management and workflow control needs. Every feature available in GitLab CE, is also available on GitLab Enterprise Edition (Starter and Premium), and GitLab.com.
  • GitLab Enterprise Edition (EE): Open core, self-hosted, fully featured solution of GitLab. Available in two different subscriptions:
    • GitLab Enterprise Edition Starter (EES): Ideal for co-located teams who need additional security and workflow controls for their professional projects.
    • GitLab Enterprise Edition Premium (EEP): Ideal for distributed teams who need advanced workflow controls, advanced CI/CD, advanced Monitoring, advanced Project Management, and High Availability.
  • GitLab.com: SaaS GitLab solution, with free and paid subscriptions. GitLab.com is hosted by GitLab, Inc. Ideal for individuals who want to get their projects up and running quickly. Administrated by GitLab (users don't have access to admin settings).

Cover image licensed under CC0

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions RSS

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Enterprise Edition risk-free for 30 days.

No credit card required. Have questions? Contact us.