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 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! 🙌
Key improvements released in GitLab 9.5
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!
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.
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.
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.
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.
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
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
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.
MR Widget Links to Repository
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.
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
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.
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
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
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
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
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.
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
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.
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.
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.
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.
“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.
GitLab Geo Improvements
Notable changes:
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.
Planned removal 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.
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.
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
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
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
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.
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.
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
-
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