9.2

GitLab 9.2 Release

GitLab 9.2 released with Multiple Assignees for issues and Pipeline Schedules

GitLab 9.2 Released with Multiple Assignees for Issues, Pipeline Schedules, Localization, Disaster Recovery Alpha Improvements and much more!

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

GitLab MVP badge

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

9.2 Key improvements released in GitLab 9.2

Multiple Assignees for Issues

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.

Multiple Assignees For Issues

Internationalized Cycle Analytics

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.

Internationalized Cycle Analytics

Pipeline Schedules

Pipeline Schedules

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.

Pipeline Schedules

Official GitLab installation on Kubernetes

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!

Official GitLab installation on Kubernetes

App Performance Feedback on Merge Requests

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!

App Performance Feedback on Merge Requests

Disaster Recovery Alpha Improvements

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.

Disaster Recovery Alpha Improvements

Auto-Refresh on Issue Titles and Descriptions

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.

Auto-Refresh on Issue Titles and Descriptions

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.

Remove Filter in Search Bar

Advanced search with Elasticsearch

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.

Advanced search with Elasticsearch

9.2 Other improvements in GitLab 9.2

Create Merge Request from Issue

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.

Create Merge Request from Issue

Comments for Personal Snippets

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

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.

Rendered Code Preview

Terraform Support for GitLab Runner on Google Compute Engine

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

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.

Job Artifacts Preview in UI

Handling of Ambiguous Routes in Dynamic Paths

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

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.

Deletion of branches after a merge request is merged is now on by default

Artifacts are Restored after Cache Files in CI Jobs

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.

Omnibus Improvements

Omnibus Improvements

GitLab Mattermost 3.9

GitLab 9.2 includes Mattermost 3.9, an open source Slack-alternative, which adds a new integrations directory, Polish support, upgraded desktop apps with spellchecker, and much more.

This version includes security updates and an upgrade is recommended.

GitLab Registry

The GitLab Container Registry has been updated from 2.4 to 2.6.1.

Select Individual Approvers for Merge Request Approvals

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

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.

Outdated diff link

Diff comment

Deploys shown on Performance Dashboard

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!

Deploys shown on Performance Dashboard

Manual Actions Respect Protected Branches

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

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.

Failed Jobs Tab allows you to access to a summary of all the failures quickly

Usage Ping

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

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

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

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 Deprecations

Vendor support for Ubuntu 12.04 and OpenSUSE 13.2

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

  1. 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.
  2. You have to use post-deployment migrations.
  3. 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 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