GitLab is designed to allow everyone to contribute whether their teams are large or small, remote or in a single room.
As a new feature or product is moving from idea to production, often multiple people work on the same issue together. For example, it is not uncommon to have a front end developer, backend developer, UX designer, QA tester, and product manager teaming together to bring an idea to market. With 9.2, GitLab introduces Multiple Assignees for Issues to streamline collaboration and allow these shared responsibilities to be clearly displayed. All assignees are shown across our workflows and receive notifications as they would before, simplifying communication and ownership.
GitLab 9.2 also lays the foundation for the localization of GitLab, with Cycle Analytics now available in Spanish and German languages. In future releases we will continue to localize additional workflows within GitLab, to ensure that everyone can contribute regardless of their native language.
Developers also have additional control over when their CI/CD Pipelines execute. We have added the ability to configure pipelines to run on a specific schedule automating repetitive tasks like the creation of nightly builds, maintenance, or validation of external dependencies.
Join us for an upcoming event
This month's Most Valuable Person (MVP) is awarded to
Dosuken Shinya
Dosuken extended our Pipelines API by adding additional search attributes. This is a huge improvement to our CI API, for example enabling queries to easily return the latest pipeline for a specific branch, as well as a host of other possibilities. Dosuken also made a great contribution last release, laying the foundation for scheduled pipelines. Thanks Dosuken!
Key improvements released in GitLab 9.2
Multiple Assignees for Issues
On GitLab, it is not uncommon to have issues that require the collaboration of multiple individuals.
In the past it could be difficult to track the shared ownership of an issue, especially in organizations
where the issue’s contributors may not work together day to day. With this release, GitLab enables you to assign
as many users as you want to a given issue. Every one of those assignees are first
class citizens, and receive the same notifications as before. With this change,
you can see multiple assignees in the issue list and on issue boards, and the
assignees will all be able to track their association with the issue in their dashboard.
Note that as part of this change, the assignee_id parameter
in the issues API
has been deprecated. The assignee_ids should be used instead.
Also, the assignee object in the JSON response has been deprecated.
The assignees array should be used instead.
Internationalized Cycle Analytics
Hola Mundo, Hallo Welt! We are incredibly excited to announce the start of
our journey to internationalise GitLab and would love your support to make
this happen as broadly and quickly as possible.
Starting in 9.2, we have added the framework and infrastructure to translate
GitLab into any language. To validate our technology decisions, we've only
translated a single page (Cycle Analytics) into Spanish and German. In 9.3
and subsequent releases, we will continue to add more languages and more
pages. If you want to help out, please take a look at our
contributor Guidelines.
To change your language, visit your Settings page by clicking on yourself in the top right corner.
For most projects, developers want to have their GitLab CI/CD pipelines
executed for every new commit, ensuring any changes are built, tested and
deployed. In some cases however, a developer needs extra control and
would instead like a pipeline to execute on a specific schedule.
Today with GitLab 9.2, pipelines can now be configured to run
when and how often you need them to.
Generating daily or weekly builds, performing maintenance, or even
validating external dependencies can be easily configured to run on your schedule.
This replaces the alpha UI for
Scheduled Pipelines Triggers.
Official GitLab installation on Kubernetes
We want to make GitLab the best cloud native development tool, so making it easy to get started on Kubernetes is important.
With GitLab 9.2, we are proud to announce that we have released official GitLab Helm charts.
Helm is the official Kubernetes package management tool allowing users to easily deploy, upgrade, and configure apps in their clusters.
GitLab and Kubernetes go great together with easy autoscaling CI, app autodeployments to your clusters and everything else shown in the Idea to Production video - out of the box, minimal setup!
App Performance Feedback on Merge Requests
For most companies, determining the performance impact of a specific
merge can be a challenge. Often performance data is contained within a
separate tool, which the development team may not even have access to.
At GitLab we want to make sure developers get feedback on every change
they ship, and we are taking a big step forward today with our Prometheus integration.
With GitLab 9.2, we now automatically
display the change in memory consumption after a deploy directly on
its merge request. This allows the developer to quickly and easily determine
if there are any performance changes and investigate as soon as possible,
all within their usual daily workflow. In future releases, we will analyze additional metrics as well. Building responsive and delightful apps is everyone's responsibility!
Disaster Recovery Alpha Improvements
Since version 9.0, GitLab ships with support for Disaster
Recovery in Alpha as part of GitLab Geo. We are committed to making
Disaster Recovery better on every release, and GitLab 9.2 is no
exception. Today we are improving the UX of the Disaster Recovery
feature, with more obvious controls and more reporting on what’s
going on during the replication process.
Finally, we had also made improvements to the repositories
synchronization mechanism, and now it is smart enough to resync
broken repositories due to a failed sync or repositories that
have been recently updated on the primary node but have been
synced some time ago on the secondaries.
Auto-Refresh on Issue Titles and Descriptions
The issue page in GitLab is a key area of collaboration, with you and
your team constantly editing content. When viewing an issue page, the title and description
now refresh automatically (in response to someone else changing it) to keep up with your workflows.
The issue page itself doesn’t reload. So you can simply leave a browser tab open to an issue you are
interested in, and you’ll always be seeing the latest information. Even the browser tab title
refreshes by itself.
We've also added a system note when an issue description is edited, so
you can always scroll through the comment thread and see who made
any changes, and when. Even adding comments now feels more responsive.
And if you edit an existing comment, that comment will also be
automatically refreshed on any other user's screen who happens to have the
same issue open.
Remove Filter in Search Bar
You can now easily remove filters in the search bar for issues and merge
requests with a simple mouse click.
We've also styled the labels within the filter bar to match the colors they have elsewhere.
Advanced search with Elasticsearch
We are bringing more advanced search capabilities leveraging Elasticsearch integration.
Provided you have configured Elasticsearch, you can search for exact phrases using
double quotes, search for content ignoring the order of search terms, match partial
words, and other syntax. (Note that this applies to the search box in the top right
corner throughout GitLab, and not the search bar inside issue lists and merge request lists.)
You can now also search globally across all wikis in your instance, again requiring
and powered by Elasticsearch.
Other improvements in GitLab 9.2
Create Merge Request from Issue
With each iteration of GitLab, we strive to make going from idea
to production faster and smoother.
This new small tweak allows you create a merge request
right from the issue page, with GitLab creating the associated
branch automatically in the background for you. It's especially
useful when you want to make simple code commits right inside GitLab.
Comments for Personal Snippets
Collaboration often happens in snippets, even personal snippets. With this
release, you now have a comment thread for each personal snippet, just like project snippets.
Rendered Code Preview
Many files, such as SVG & Markdown are displayed in GitLab’s
file view in their rendered form. Sometimes, it’s much more useful
to see the actual code. We’ve now added a handy little switch on the
file view, which means you can now easily switch between the rendered
preview and the raw code.
Terraform Support for GitLab Runner on Google Compute Engine
As part of GitLab 9.1, we launched support for installing GitLab on GCE via
Hashicorp’s Terraform.
With 9.2 we are also adding the ability to deploy GitLab Runner as well,
allowing you to complete the idea to production cycle!
Job Artifacts Preview in UI
Artifacts can be files of any kind, and you have access to them by browsing the archive directly from UI.
GitLab 9.2 improves this capability further: now PDFs, images, videos and other formats can be previewed
directly in the job artifacts browser without the need to download them.
Handling of Ambiguous Routes in Dynamic Paths
There are several paths that GitLab uses to access certain features. With the introduction of nested groups these features could become unavailable for projects or groups with names that conflict with these paths. For example: for a project called 'badges' the build and coverage status badges would become unavailable.
To avoid confusion, it is now no longer possible to create projects or groups with names that could clash with existing GitLab routes.
If you had any projects or groups named like one of these routes, they will have been automatically renamed during the upgrade. A project named badges would be renamed to badges0.
Keep in mind that git-remotes would need to be updated locally as well. That can be done like this:
git remote set-url origin <[email protected]:the-updated-path/the-updated-name.git>
The full list of reserved words can be found in the dynamic_path_validator.rb file. The list of existing projects and groups that were renamed in this release can be found in the migration that renamed them.
Deletion of branches after a merge request is merged is now on by default
Starting with GitLab 9.2, the deletion of the source branch in a merge
request is selected by default. If you want to keep the branch around
even when the merge request is merged, you’ll have to uncheck the option
from the merge request widget before merging.
Artifacts are Restored after Cache Files in CI Jobs
It may happen that someone, by mistake or by purpose, uses the same path in .gitlab-ci.yml for both cache and artifacts keywords,
and this could cause that a stale cache might inadvertently override artifacts that are used across the pipeline.
Starting with this release, artifacts are always restored after the cache to ensure that even in edge cases you can always rely on them.
Select Individual Approvers for Merge Request Approvals
Configuring merge request approvals allows for selecting individual
approvers. The process is even easier, with the search now limited
to project members and users in relevant groups (parent group or groups
with access via a project share) in the project settings and the per
merge request settings, so that you can easily identify relevant users.
Commenting in Outdated Diffs
With this release, you can now link directly to an outdated diff
from the merge request discussion thread, allowing you to quickly
refer to older commits during code development, collaboration, and
review. You can even comment in that previous outdated diff as well.
Deploys shown on Performance Dashboard
When investigating a change in performance behavior, one of the first questions
asked is always if there have been any changes to the environment. GitLab 9.2
now quickly answers this question by showing all deployments to an environment
directly on the monitoring dashboard. This allows easy correlation between any
changes in performance and a new version of the app, all without leaving GitLab!
Manual Actions Respect Protected Branches
Manual actions
now require the same permissions as a repository write, allowing control over
who can trigger them. For example, triggering a manual deploy job to production
from the master branch can now be restricted to a narrower set of users with
access to commit.
This is a very important item in the list of security enhancements
we're bringing into GitLab in order to protect your deployment process,
you can read more in this issue.
Failed Jobs Tab allows you to access to a summary of all the failures quickly
When you commit new code to a project with continuous integration configured you normally expect to see a green check:
this tells you the pipeline succeeded and everything worked as expected.
In the unfortunate case something went wrong, you might want to know exactly what has failed as quick as possible,
but walking through multiple stages and jobs could be frustrating, expecially if your pipeline is very complex.
GitLab 9.2 introduces a new tab in the Pipeline view: you can now directly go to Failed Jobs and see
the detailed list of jobs that were unsuccessful in one single place, having a big picture of the actual status.
Usage Ping
This release contains two changes to the usage ping: you can now opt-out of the usage ping through your configuration in gitlab.rb. This allows you to turn off the usage ping before having started GitLab. You were already able to opt-out through the administration panel and this remains the case.
In addition, we now include the hostname in the usage ping, similar to the version check. For more, see the documentation on the usage ping.
Docker Registry Cleanup Tool
We’re glad to announce that an alpha version of our
Docker Container Registry maintenance tool
is available to the public. This tool analyzes the
container registry
and prunes unreferenced versions of tags, manifests, and layers to reclaim storage space.
If you're enthusiastic to experiment with how it works,
you're encouraged to test it out and report your feedback!
GitLab Runner 9.2
We're also releasing GitLab Runner 9.2 today!
Most interesting changes:
- Support for TLS client authentication (merge request)
- PodLabels setting for Kubernetes executor configuration (merge request)
- Support for Kubernetes Service Account in Kubernetes executor configuration (merge request)
List of all changes can be found in GitLab Runner's CHANGELOG.
Performance Improvements
With every release of GitLab we look to make significant improvements to the performance. In GitLab 9.2, the following areas should see visible improvement:
- Listing groups
- Listing projects
- Listing merge requests
- Listing milestones
- Push mirrors should no longer put pressure on filesystem and sidekiq queues
Here is a full list of performance improvements in GitLab 9.2.
Deprecations
Vendor support for Ubuntu 12.04 and OpenSUSE 13.2
Vendor support for Ubuntu 12.04 and OpenSUSE 13.2 has ended.
GitLab will no longer provide support or packages for these platforms.
Planned removal date:
May 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.2, no downtime is required.
However we're also migrating data for CI jobs. If you have a significant number of jobs, this could take some time.
Starting with GitLab 9.1.0 it's possible to upgrade to a newer version of GitLab
without having to take your GitLab instance offline. However, for this to work
there are the following requirements:
- You can only upgrade 1 release at a time. For example, if 9.1.15 is the last
release of 9.1 then you can safely upgrade from that version to 9.2.0.
However, if you are running 9.1.14 you first need to upgrade to 9.1.15.
- You have to use post-deployment migrations.
- You are using PostgreSQL. If you are using MySQL you will still need downtime
when upgrading.
This applies to major, minor, and patch releases unless stated otherwise in a
release post.
A new version of our API was released in GitLab 9.0.
While existing calls to API v3 will continue to work until August 2017, we
advise you to make any necessary changes to applications that use the v3 API.
Read the documentation to learn
more.
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