GitLab.org/GitLab: Release v9.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 9.2
Released: 2020-04-03
License: MIT
Release Assets:
  #### [Premium](https://about.gitlab.com/pricing/premium/)  
[Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#3-1-multiple-assignees-ees-eep)
> 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.
>
[Disaster Recovery Alpha Improvements](https://docs.gitlab.com/ee/administration/geo/) (self-managed only)
> 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.
[Advanced search with Elasticsearch](https://docs.gitlab.com/ee/user/search/advanced_search.html)
> 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.
[Select Individual Approvers for Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html)
> 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.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.
[Pipeline Schedules](https://docs.gitlab.com/ee/ci/pipelines/schedules.html)
> 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](https://docs.gitlab.com/ee/install/kubernetes/) (self-managed only)
> 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](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#determining-the-performance-impact-of-a-merge)
> 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!
[Auto-Refresh on Issue Titles and Descriptions](https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html)
> 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](https://docs.gitlab.com/ee/user/search/#issues-and-merge-requests-per-project)
> 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.
[Create Merge Request from Issue](https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#18-new-merge-request)
> 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](https://docs.gitlab.com/ee/user/snippets.html#comments)
> 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.[Commenting in Outdated Diffs](https://docs.gitlab.com/ee/user/project/merge_requests/)
> 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. > >
>
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.[Deploys shown on Performance Dashboard](https://docs.gitlab.com/ee/ci/environments/index.html#monitoring-environments)
> 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 (self-managed only)
> 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!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.
[Job Artifacts Preview in UI](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-job-artifacts)
> 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.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.
[Handling of Ambiguous Routes in Dynamic Paths](https://docs.gitlab.com/ee/user/group/subgroups/index.html#creating-a-subgroup)
>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 <git@gitlab.com: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.
[Usage Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#usage-ping) (self-managed only)
>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.
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.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!
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.
[GitLab Runner 9.2](https://docs.gitlab.com/runner/)
>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.
Omnibus Improvements (self-managed only)
>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.
[Performance Improvements](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=performance&milestone_title=9.2)
>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.