GitLab.org/GitLab: Release v11.4.0-ee

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

![39 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=39&style=for-the-badge "New features added in this release") ![520 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=520&style=for-the-badge "Total features") #### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![3 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=3&style=flat-square "New features added to this tier in this release") ![48 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=48&style=flat-square "Total features in this tier")

[Close epics](https://docs.gitlab.com/ee/user/group/epics/)

> Similar to issues and merge requests, you can now close (and re-open) epics > in GitLab. The epics list now has the Open, Closed, and All tabs, just like > issues. So when you have completed all the work in an epic, or it is no > longer relevant, you can close it, and it won't appear anymore in the default > list view. > > You can close (and re-open) an epic via buttons on the epic, via quick actions > in an epic comment, and also via the API, exactly like issues.

[Add manual entries for License Management](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html#project-policies-for-license-compliance)

> License Management policy allows developers to define if they want to approve or blacklist > a specific license for their project. This can be done as soon as a new license is introduced, > directly in the merge request page. But sometimes project maintainers want to populate the > list beforehand, so that developers already know if their changes are aligned with the policy. > > In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project > maintainers can prefill the policy in the **Settings > CI/CD > License Management** page by > choosing from a set of common licenses, or add a custom entry to that list.

[Alert thresholds now displayed on metrics dashboard](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics)

> With GitLab 11.4, configured alert thresholds are now displayed directly on the metrics charts. > This allows easier determination of which metrics are currently generating alerts, and better > visualization of the interplay of the metric and alert threshold.

#### [Premium](https://about.gitlab.com/pricing/premium/) ![9 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=9&style=flat-square "New features added to this tier in this release") ![102 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=102&style=flat-square "Total features in this tier")

[Merge Request Reviews](https://docs.gitlab.com/ee/user/discussions/index.html)

> Code review in merge requests is a powerful feature in GitLab. Team members > have conversations linked to specific lines of code in a diff, and can even > resolve them. However, the process can get unwieldy in merge requests with > large diffs. Often, a reviewer may need to leave upwards of 10 or more comments > in a single sitting. And the 9th or 10th comment may actually render earlier > comments unnecessary. The end result is that the merge request author > gets a slew of notifications and has to sort them out one by one. > > With this release, we are introducing Merge Request Reviews. This will > allow a reviewer to draft as many code comments in a merge requests as they > wish, make sure they are all consistent, and then submit them all > as a single action. Since the drafts are saved to GitLab, a reviewer can > even spread their work over many sessions, say starting a review on their > desktop at work during the day, and then wrapping it up at home on their > tablet device later in the evening. Once the draft comments are submitted, > they appear as normal individual comments. This allows individual team members > the flexibility to do code review however they want, but still being compatible > with the entire team. > > In future iterations, we will improve the feature to provide a > [preview](https://gitlab.com/gitlab-org/gitlab-ee/issues/4327) > before the batch submit action, and also combine all those notifications > that those comments currently generate, into > [one batched notification](https://gitlab.com/gitlab-org/gitlab-ee/issues/4326).

[Create and toggle feature flags for your applications (alpha)](https://docs.gitlab.com/ee/operations/feature_flags.html)

> This feature gives you the ability to create and manage feature flags for > your software directly in the product. Simply create a new feature > flag, validate it using the simple API instructions in your software, > and you have the ability to control the behavior of your software > in the field via the feature flag within GitLab itself. > > Feature Flags offer a feature toggle system for your application. > They enable teams to achieve Continuous Delivery by deploying new > features to production in smaller batches for controlled testing, > separating feature delivery from customer launch. This helps reduce > risk, and allows you to easily manage which features to enable. > > Note that this is an alpha feature being introduced for the first time, > so while we encourage you to check out the feature and provide feedback, > we want you to be aware that the implementation could change in subsequent > releases.

[Suggest Code Owners as merge request approvers](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html)

> Knowing who is the best person to review your changes isn't always > obvious. Code owners are now shown as suggested approvers when creating > or editing a merge request to make assigning the right person easy. > > Support for defining code owners was introduced in > [GitLab 11.3](/releases/2018/09/22/gitlab-11-3-released/#code-owners). In > upcoming releases, code owners will be further integrated into the > merge request workflow with > [automatic assignment](https://gitlab.com/gitlab-org/gitlab-ee/issues/1012) > and > [required approvals](https://gitlab.com/gitlab-org/gitlab-ee/issues/4418).

[Add timed incremental rollouts to Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#timed-incremental-rollout-to-production)

> You've had the ability within Auto DevOps to setup incremental > rollouts for a while now, and with this release, we are adding > an option to also set up _timed_ incremental rollouts where > the rollout will automatically continue on a timed cadence > unless there is some error.

[Include new issues created in Burndown Chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)

> Burndown Charts help teams track work, as it progresses throughout a milestone. > Usually, the scope of work is decided and agreed on before the milestone > begins. But occasionally, there will be important exceptions to the rule, > (such as an emergency bug or security fix) and new scope needs to be included, > in the form of new issues. > > With this release, burndown charts now accounts for these > new issues that are created in the middle of a milestone, resulting in an > uptick of its line.

[Expanded weight values in issues API](https://docs.gitlab.com/ee/api/issues.html)

> In a previous release, we expanded the allowable values of issue weight > from a small number to effectively unlimited, any number greater than zero. > > With this release, we've brought this flexibility to the issues API as well, > allowing users to set this field with the newly expanded number range with > the API.

[Geo UX improvements in Admin Area](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html) (self-managed only)

> As a Geo admin, keeping an overview of your secondary nodes setup and the synchronization > state is crucial when working with distributed teams. > > With GitLab 11.4, we improve the Geo-related Admin Area settings by improving and showing even > more synchronization and verification details in the user interface. On your primary node, a > new button "Open projects" adds a new quick link to navigate to the "Projects" list of the > corresponding secondary node. > On secondary nodes, a new "All" tab gives you a quick overview about the verification state > of all projects. > > [Further UX improvements](https://gitlab.com/groups/gitlab-org/-/epics/369) are in our pipeline!

[Geo improvements](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html) (self-managed only)

> We continually focus on improving our [Geo](/solutions/geo/) feature for distributed teams. Some of the additional noteworthy improvements in GitLab 11.4 include: > > - [Major performance improvements](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=✓&state=closed&label_name%5B%5D=Geo%20Performance&milestone_title=11.4) > - [Include keep-around references in checksum calculation](https://gitlab.com/gitlab-org/gitlab-ee/issues/5196) > - [Migrating uploads to object storage does no longer leave behind local files](https://gitlab.com/gitlab-org/gitlab-ee/issues/7108) > - [Primary node repository verification now always gives the correct checksum](https://gitlab.com/gitlab-org/gitlab-ee/issues/7213) > - [Reliable Sidekiq queueing ensures data integrity](https://gitlab.com/gitlab-org/gitlab-ee/issues/7279) > > Read our fresh blog post on [how we built GitLab Geo](/blog/2018/09/14/how-we-built-gitlab-geo/).

[Geo improvements for SSH Git commands proxy to primary node](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html)

> Making Geo as easy to use as possible is one of our constant goals to support widely distributed > teams using GitLab. In [11.3](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/#geo-improvements) > we added initial support for proxying SSH `git push` from secondary nodes to primary nodes. > > With this release, we further improve the performance and usability of this feature, allowing > to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.

#### Core ![27 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=27&style=flat-square "New features added to this tier in this release") ![370 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=370&style=flat-square "Total features in this tier")

[File tree for browsing merge request diff](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-diff-file-navigation)

> Code review is an essential practice of every successful project, but > knowing what has changed can be hard to determine from a flat list of > diffs. GitLab now includes a searchable file tree of changes to make it > easy to see which files have changed and jump between them. > > The file tree summarizes the structure and size of the change, similar > to `diff-stats`, providing an overview of the change and improving > navigation between diffs. Search allows reviewers to limit their code > review to a subset of files by path or filetype, simplifying reviews by > specialists focussed on only a subset of the merge request. > > Previously the list of changed files was available through a searchable > drop down, that was best suited to jumping to a specific file.

[New user profile page overview](https://docs.gitlab.com/ee/user/profile/#user-profile)

> No matter how engaged you are on GitLab, your activity is a relevant > source of information and engagement indicator, displayed right at your > personal profile page. Your personal profile should give a simple insight > into what you are interested in and working on. > > With this release, we introduce a redesigned profile page overview, showing > your activity via the familiar but shortened contribution graph with your > latest activities and your most relevant personal GitLab projects.

[Set and show your status message within the user menu](https://docs.gitlab.com/ee/user/profile/#current-status)

> With [GitLab 11.2](/releases/2018/08/22/gitlab-11-2-released/#personal-status-messages) > we introduced personal status messages for the first time, allowing you to > share your current availability, mood, or simply your favorite animal. > > With this release, we make setting your status even more simple and > frictionless. A new "Set status" item in your user menu provides a fresh > modal that allows you to set and clear your status right within context. > In addition, your set status is also shown in your user menu, on top of > your full name and user name, including set Emoji and message.

[Move ability to use includes in .gitlab-ci.yml from Starter to Core](https://docs.gitlab.com/ee/ci/yaml/#include)

> We are very happy to announce in this release that the usage of > includes within the `.gitlab-ci.yml` is now available in Core. This > will help ensure templates and other shared resources are always > compatible between free and non-free users, and also unlocks the > ability for everyone to do best-practice development using reusable > snippets in your CI/CD pipelines.

[Run jobs only/except for modifications on a path or file](https://docs.gitlab.com/ee/ci/yaml/#onlyrefs--exceptrefs)

> A popularly requested feature, we're proud to now offer the > ability within the `.gitlab-ci.yml` to use `only`/`except` rules for jobs > based on when modifications occur to a specific file or path (glob). > > This will allow more control for users whose repositories contain different > kinds of assets or builds, ensuring only the appropriate steps are > executed for the kinds of changes that were committed, speeding up > overall pipeline execution.

[Support Kubernetes RBAC for GitLab managed apps](https://docs.gitlab.com/ee/user/project/clusters/#role-based-access-control-rbac)

> Security is paramount when setting up your infrastructure for the first time or connecting to > existing one. Role-based access control (RBAC) was made generally available as part of Kubernetes' > 1.8 release, providing more granular controls to regulate access to Kubernetes resources. > > Our Kubernetes integration will now offer the capability to either create an RBAC-enabled > cluster on GKE or to connect with an existing cluster that is RBAC-enabled, providing increased > security for your infrastructure.

[Auto DevOps support for RBAC](https://docs.gitlab.com/ee/topics/autodevops/)

> Auto DevOps now supports interacting with and deploying applications to RBAC-enabled Kubernetes clusters. > > Role-based access control (RBAC) is an important tool that allows operators to ensure the reliability, > security, and efficiency of their Kubernetes cluster. Using Auto DevOps in conjunction with an RBAC-enabled > cluster ensures your applications take advantage of the increased infrastructure security.

[Support PostgreSQL DB migration and initialization for Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy)

> Using Auto DevOps to automatically detect, build, test, deploy, and monitor your application > just got more powerful. Starting in 11.4, Auto DevOps now provides the ability to initialize or > migrate PostgreSQL databases in your project. > > Simply define a project variable to initialize or migrate your PostgreSQL database, and Auto DevOps > will do the rest.

[List of subscribed labels](https://docs.gitlab.com/ee/user/project/labels.html#searching-for-project-labels)

> Labels in GitLab are very powerful since they can be applied to issues, > merge requests, and epics. As you use more labels, it can be difficult to > maintain them. > > In a recent previous release, we added the ability to search by labels on > the project labels list page. With this release, you can now search by labels, > sort by name/created at/updated at, and even see a list of labels you have > subscribed to. This is available both in group and project labels list pages.

[Filter by WIP merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html)

> Merge requests are a core part of GitLab, allowing team members to collaborate > on code transparently. In particular, we encourage teams to share their > work early, and use the WIP (work in progress) feature to indicate that > a merge request is still undergoing active work and should not be merged > yet. > > With this release, we're making it easier for users to differentiate > between WIP and non-WIP merge requests by having a dedicated filter in > both group-level and project-level merge requests lists. This allows users > to quickly focus in on merge requests that are still in their early stages > of work, versus those that are toward the final stages of review before > merge.

[Highlight @mentions for yourself distinctly](https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#13-mentions)

> When collaborating in a long discussion in an issue or merge request, often > many users are involved, making it difficult to quickly at a glance, see > comments that are directed at you. > > With this release, `@mentions` for yourself (i.e. the current user), are highlighted > in a different color, allowing you to easily see which comments involve you, > helping you focus on them quickly.

[Click to insert Markdown table and link](https://docs.gitlab.com/ee/user/markdown.html)

> GitLab supports GitLab Flavored Markdown (GFM) in most places throughout > GitLab where you enter text, providing the power of rich formatting with > a simple syntax. In particular, you can create tables in GFM. Previously, > this was painful to use, especially for large tables, since you had to type > a lot of characters or paste in a previous table just to format it the way > you want. Similarly, GFM also supports URL links. But sometimes you may > forget the particular syntax. > > With this release, you can now click on the table button in the GFM editor, > and this will automatically insert a table for you. You can then easily > enter table values or extend the table, formatting it just the way you want. > You can use this in description and comment boxes all throughout GitLab. > > You can now also click on the link button, and this will generate the URL > link syntax skeleton for you. Allowing you to quickly paste in a link and > write the name of it. > > Thank you [George Tsiolis](https://gitlab.com/gtsiolis) for the table contribution! > > Thank you [Jan Beckmann](https://gitlab.com/kingjan1999) for the URL link contribution!

[Lock discussion quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html)

> Locking discussions in issues and merge requests is helpful to direct conversations > to newer issues (or merge requests). It can also be used to control abusive > or otherwise unproductive behavior. > > With this release, we now have quick actions to lock and unlock discussions, > making it easier to type a comment and lock/unlock all one action. > > Thank you [Mehdi Lahmam](https://gitlab.com/mehlah) for the contribution!

[Improve Admin Area settings structure](https://docs.gitlab.com/ee/administration/settings/) (self-managed only)

> Depending on your responsibilities, administrating GitLab can provide > a very complex challenge due to all things GitLab offers. > > With this release, we improve the experience of our Admin Area Settings by > moving all sections into new, individual Settings sub-pages. This provides > admins a time-saving shortcut to access any detail to manage.

[Explore projects by popularity](https://docs.gitlab.com/ee/user/search/#projects)

> At GitLab, we do our best to enable you to explore relevant and cool projects > on your GitLab instance. > With this release, a new filter "Most stars" provides an incredible useful > filter to show projects most starred on your instance. > > Thank you for this contribution, [Jacopo Beschi](https://gitlab.com/jacopo-beschi)!

[Display code language percentage on project overview](https://docs.gitlab.com/ee/user/project/repository/#repository-languages)

> We recently introduced a new code language bar on the Project overview page, > providing a quick overview about programming languages involved. > > With GitLab 11.4, we introduce an additional absolute measure by showing > a new percentage value for each relevant code language shown. This provides > a more quantitative view of your project's technology stack. > > Thank you for this contribution, [Johann Hubert Sonntagbauer](https://gitlab.com/johann.sonntagbauer)!

[Download two-factor recovery codes](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#recovery-codes)

> Two-factor authentication is a de facto standard for signing up for any relevant web-based > application. At GitLab we understand and take this seriously. Whenever you set up a two-factor > authentication initially, we provide limited recovery codes that allow you to regain access > to your account as a fallback. > > With this release, we now support download of recovery codes as a text > file using the new "Download codes" button. > > Thank you for this contribution, [Luke Picciau](https://gitlab.com/Qwertie)!

[Filter admin Runners view by Runner type and state](https://docs.gitlab.com/ee/ci/runners/) (self-managed only)

> The admin runner view now supports the ability to filter > by runner type and state, giving you more options to manage > especially large fleets of runners in your environment.

[Add support for interactive web terminal to Docker executor](https://docs.gitlab.com/ee/ci/interactive_web_terminal/) (self-managed only)

> The interactive web terminals feature has been expanded to be > compatible with Docker executors as well. For now, the Docker session > is closed as soon as the script exits, but we are aiming to further > improve this behavior by resolving [#3605](https://gitlab.com/gitlab-org/gitlab-runner/issues/3605) in > our next release.

[Skip Auto DevOps jobs based on feature availability](https://docs.gitlab.com/ee/topics/autodevops/)

> Starting in 11.4 Auto DevOps will now evaluate the plan (GitLab.com) or tier (self-managed) > for the instance in which it's running in order to determine which jobs to skip. This will > result in faster Auto DevOps pipeline when certain features are not in use. > > This will not only save you time but will also result in a cleaner view of Auto DevOps pipeline, > showing you only the relevant jobs for your project.

[Allow pipelines to schedule delayed jobs](https://docs.gitlab.com/ee/ci/yaml/#when)

> It is now possible to set a job to start after a delay > via the `when` keyword in `.gitlab-ci.yml`. The timer starts > ticking when the job would have otherwise started, giving you > control to implement tasks that need to wait for a period of time to occur - for > example, when implementing timed incremental rollouts, or any > other delays needed after performing some other action.

[Interactive runbooks with Nurtch and JupyterHub](https://docs.gitlab.com/ee/user/project/clusters/runbooks/)

> Interactive runbooks provide a powerful way for operators to interact with various systems to carry out > common tasks such as diagnosing, deploying, and measuring infrastructure components. > > The JupyterHub app offered via GitLab's Kubernetes integration now ships with Nurtch's > [Rubix library](https://github.com/amit1rrr/rubix), providing a simple way to create DevOps > runbooks. A sample runbook is provided, showcasing [common operations](https://youtu.be/Q_OqHIIUPjE).

[Git protocol v2](https://docs.gitlab.com/ee/administration/git_protocol.html)

> Developers fetch refs many times a day to check if the current branch > is behind the remote branch. Git protocol v2 is a major update to Git's > [wire protocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html) > which defines how clones, fetches, and pushes are communicated between > the client (your computer) and the server (GitLab). The new wire > protocol improves the performance of fetch commands and enables future > protocol improvements. > > Previously, all responses to fetch commands included a list of all > references in the repository. For example, fetching updates for a > single branch (e.g. `git fetch origin master`) would also retrieve a > complete list of all references. In the case of large projects, this > could be over 100,000 refs and 10s of megabytes of data. > > Git protocol v2 is supported from Git v2.18.0 and is opt-in. To enable > globally run `git config --global protocol.version 2`. Git protocol v2 > over SSH is not yet enabled on GitLab.com and must be enabled manually > for self-managed installations.

[Prometheus 2.0 upgrade for Omnibus GitLab](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4) (self-managed only)

> Omnibus GitLab comes out of the box with Prometheus, allowing [easy observability of deployed instances](https://docs.gitlab.com/ee/administration/monitoring/prometheus/). > The Prometheus team has released a major new version, the 2.x series, which offers a > [number of improvements](https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/). > These include improved performance and a more efficient time-series database format. Unfortunately > because of the architectural changes to the database, it is not backwards compatible with the old 1.x format. > > With GitLab 11.4, Prometheus 2.4.2 is now available in the Omnibus package so users can take advantage of its benefits. > > - New installations of 11.4 and above will start with Prometheus 2. > - Existing installations will not be automatically upgraded. We have added a new command, `gitlab-ctl prometheus-upgrade`, which can > be utilized to [upgrade Prometheus and optionally migrate data](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4). Prometheus will be stopped during data migration. > - GitLab 12.0 will [automatically upgrade to Prometheus 2.0](#deprecations). With the automatic upgrade, Prometheus 1.0 data will not be migrated. > > For more information on upgrading Prometheus to 2.4.2, please review our [update documentation](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4).

[GitLab Runner 11.4](https://docs.gitlab.com/runner)

> We're also releasing GitLab Runner 11.4 today! GitLab Runner is the open source project > that is used to run your CI/CD jobs and send the results back to GitLab. > > #### Most interesting changes: > > - [Support JSON logging](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1020) > - [Add docker support for interactive web terminal](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1008) > - [Add support docker machine web terminal support](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1046) > - [Allow disabling docker entrypoint overwrite](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/965) > - [Add metrics with concurrent and limit values](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1019) > - [Add a gitlab_runner_jobs_total metric](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1018) > - [Add a job duration histogram metric](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1025) > - [Fix command and args assignment when creating containers with K8S executor](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1010) > > List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.4.0/CHANGELOG.md).

[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)

> - `redis` has been updated to 3.2.12, which is a critical security update that fixes multiple vulnerabilities. After upgrading to 11.4, run `sudo gitlab-ctl restart redis` to ensure the new version is running. > - GitLab 11.4 includes [Mattermost 5.3](https://mattermost.com/blog/mattermost-5-3-enhanced-search-on-desktop-and-mobile-plugin-hackathon-highlights-and-more/), > an [open source Slack-alternative](https://mattermost.com/) whose newest release includes enhanced search on desktop and mobile, plus much more. > It includes [security updates](https://about.mattermost.com/security-updates/) and upgrading is recommended. > - `git` has been updated to 2.18.1, and `libpng` to 1.6.35. > - `gnupg` has been updated to 2.2.10, `gpgme` to 1.10.0, `libgcrypt` to 1.8.3, `npth` to 1.6, `libgpg-error` to 1.32, and `libassuan` to 2.5.1. > - Certificates in the `trusted_certs` directory are now set to `0644` permissions instead of `0755`.

[Performance improvements](https://gitlab.com/groups/gitlab-org/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.4)

> Some of the more noteworthy performance improvements in GitLab 11.4 include: > > - [Rendering Markdown with many label references is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/48221) > - [Issue discussions with many cross-project commit references are faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/43094) > - [Fetching related branches for an issue runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/43097) > - [Fetching environments for a merge request runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/43109) > - [Computing recipients for notification emails runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/47496) > - [Creating a new diff discussion on a merge request is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/49002) > - [Fetching "Last commit" info in tree view makes fewer Gitaly calls](https://gitlab.com/gitlab-org/gitlab-ce/issues/37433) > - [Loading merge request is faster after removing dead code](https://gitlab.com/gitlab-org/gitlab-ce/issues/51172)