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

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! 🙌

Key features released in GitLab 9.5 GPG Commit Verification CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD 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! Documentation

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. Deprecation date: 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 . 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. 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. 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. Deprecation date: 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: Set up their GitLab instance according to “Upgrading Without Downtime”. Upgrade to 9.5.0 as soon as possible. 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.