GitLab.org/GitLab: Release v11.0.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 11.0
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
Apple just announced Xcode 10 is now integrated with GitLab pic.twitter.com/eQbtiY4IYm[License Management](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)
> In modern software development, most applications rely on external components
> to implement specific functions, preventing the need to code everything from scratch every
> time. This is why third-party libraries are so common, and fetched directly by package
> management tools like RubyGems or npm. However, this approach requires you to ensure
> that the licenses for external components are compatible with your
> application, and that there is no conflict that could lead to legal issues.
>
> In GitLab 11.0, we are proud to introduce License Management as part of our
> integrated development workflow. It automatically collects all the licenses
> used by your dependencies and displays new ones in the Merge Request widget
> before they land on your main default branch.
>
> If you are using [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/),
> License Management is
> automatically enabled for your projects. Otherwise, you can
> [manually enable it](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)
> for your custom `.gitlab-ci.yml` definitions.
[Roadmap date ranges](https://docs.gitlab.com/ee/user/group/roadmap/#timeline-duration)
> Since epics can take on any start and end dates, we wanted to provide a simple way for users
> to quickly view the ones that are more relevant in a given time range.
>
> With this release, we are introducing Roadmap date ranges. You can now quickly click Quarters, Months, or
> Weeks, and immediately, the roadmap will be refreshed, enabling you see your epics from different
> time perspectives. Teams who are focused on shipping features in the next few weeks can use one
> granularity, while executive leadership folks who want a high-level overview can use the longer
> time-period views.
[Unlimited Guests for free in Ultimate](https://docs.gitlab.com/ee/user/permissions.html) (self-managed only)
> In order to help customers get the most from their GitLab instances, Guest
> users no longer count against seat count for Ultimate licenses.
>
> Since these users no longer consume seats (they're effectively free to
> add), it gives more users in an organization the chance to join the
> instance and contribute to the conversation. You're free to promote
> these users, but they'll count against your license's seat count once
> they're promoted beyond Guest in any project or group.
>
> This also means that if a user logs in and is never added to a project/group,
> they have no role applied, therefore they are considered as 'Guests.'
[SAST for .NET and Scala](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)
> As part of our effort to increase the availability of our security tools to the most common
> languages and frameworks, we have been continuously iterating on Static Application Security Testing (SAST).
>
> In GitLab 11.0, we add support for two new languages, .NET and Scala. Users don't need to
> change anything in their projects if they are already using Auto DevOps or the latest
> version of the `sast` job definition in their `.gitlab-ci.yml` file.
[View Kubernetes pod logs](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html)
> A fundamental need for all developers is to be able to review logs in order
> to understand application behavior and troubleshoot any problems
> that arise. With GitLab 11.0,
> reviewing the logs of a troublesome pod is now just a click away.
>
> On the **Environments** page, the status of pods for each application is
> displayed using [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html).
> Mousing over the pods will display the full pod name and status,
> and clicking on the pod will then display the logs.
[SAML single sign-on for Groups (Beta)](https://docs.gitlab.com/ee/user/group/saml_sso/)
> Being able to manage user credentials at scale is a must for large
> organizations. Centralizing users on a company-controlled identity
> provider is a common solution, and we have expanded our support for
> authentication based on Security Assertion Markup Language (SAML) by
> adding it to Groups.
>
> Group owners are now able to configure an identity provider and
> provide a single sign-on (SSO) link to users. By authorizing them
> through the provided URL, groups can provide managed authentication
> when instance-wide SAML is either unfeasible or not specific enough
> for the group.
>
> This is especially important for groups on GitLab.com, which can now
> configure identity providers for enterprise use.
[Issue Board assignee lists](https://docs.gitlab.com/ee/user/project/issue_board.html#assignee-lists)
> Issue boards are a great tool for managing and tracking workflows, as your issues progress through different stages in
> your lifecycle, with label lists representing those stages.
>
> With this release, we are introducing assignee lists to issue boards. An assignee list shows issues that are assigned
> to a specific user. This provides a whole new way to use issue boards: to view and manage issue assignments for your
> team.
>
> You can now [configure a board](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-board)
> to a scope that matches that of your team, and then add assignee lists representing team members. This gives you instant
> visibility into what issues your team is working on, whether you are a manager who wants an overview and status of the team's
> overall responsibilities, or an individual contributor who wants to sync up with another team member's assigned issues.
>
> You can even add label lists and assignee lists to the same board.
[Always-on approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
> Merge request approvals are a longstanding GitLab feature that allows teams to enforce code review
> (or any type of review) in a merge request, before unblocking it for merging.
>
> Prior to this release, the feature had to be configured in the project settings. To simplify and
> streamline the feature, approvals are now always on for all projects in GitLab (in Starter, Bronze, or higher tiers).
> At the same time, however, we definitely do not want to slow down creating and merging code. So when a user
> creates a project, the required number of approvals is by default zero for the project (essentially, the
> feature is "off"). As the project grows, the user (and their team) can naturally adopt approvals by raising
> that required number as appropriate to their workflow needs.
[Expanded Issue Weight values](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)
> Issue weights in GitLab are useful for assigning effort estimation or any other cost metric
> associated with working on an issue. Previously, you could only assign values 1 through 9
> for an issue. But this meant that teams that wanted more granularity in their weighting were constrained.
>
> Starting in this release, issue weights can take on any non-negative integer value, from 0 upward, giving you
> unlimited flexibility in how you use weights. Furthermore, [Burndown Charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
> automatically consider these new weight values, so your team can immediately make use of an expanded range.
[Geo improvements](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html)
> We continously improve our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.0 include:
>
> * [`git fetch` and `git push` operations on secondary Geo nodes are now automatically redirected to the primary node when using HTTP](https://gitlab.com/gitlab-org/gitlab-ee/issues/3912)
> * [New rake tasks allow to schedule housekeeping on following repository synchronizations](https://gitlab.com/gitlab-org/gitlab-ee/issues/5928)
> * [Geo command that runs `git fsck` is now written in Go for a performance improvement](https://gitlab.com/gitlab-org/gitaly/issues/1175)
> * [When using hashed storage, the GitLab Shell log file now displays the readable repository name](https://gitlab.com/gitlab-org/gitlab-ce/issues/41229)
[Auto DevOps Generally Available](https://docs.gitlab.com/ee/topics/autodevops/)
> Originally introduced in beta in [GitLab 10.0](/releases/2017/09/22/gitlab-10-0-released/#auto-devops), Auto DevOps is now Generally Available (GA) in GitLab 11.0.
> Auto DevOps provides a complete workflow for your project with minimal configuration, efficiently taking your
> application from the build stage through the production and monitoring stage.
>
> Auto DevOps brings DevOps best practices to your project by automatically configuring your build, test, Code
> Quality, Static and Dynamic Security Testing, Dependency Scanning, License Management, Container Scanning, Review
> Apps, Browser Performance Testing, deployment, and monitoring in a single application. It makes it easy for
> teams adopting DevOps to start with a complete, holistic pipeline.
>
> Auto DevOps enables developers to focus on what matters most to the organization – shipping code that brings
> value to their customers.
>
> [Check out our revamped quick start guide.](https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html)
[CI/CD pipeline status and job traces in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#view-ci-job-logs)
> Continuous integration is an important step in shipping high-quality
> software, and you can now check the CI status of the current commit
> at a glance by checking the status bar at the bottom left of the Web IDE. Even
> better, you can view the status of each job and the logs for each job
> on the right. This makes it easy to fix a merge request with CI
> failures by opening the failed job side by side with the file you're
> working on.
>
> Previously, fixing failed tests involved opening multiple tabs and
> switching backwards and forwards. Now, all the information you need
> can be opened right in the Web IDE, and
> [in the future](/direction/)
> you'll be able to preview and test your changes before you commit them.
[Switch between merge requests in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#switching-merge-requests)
> It's common to end up working on multiple merge requests across multiple
> projects, and it now only takes one click to switch among your
> assigned and authored merge requests. Whether you are reviewing others' merge
> requests, or trying to get your own over the line, the new
> merge request switcher allows you to spend more time coding and
> less time searching.
[New navigation themes](https://docs.gitlab.com/ee/user/profile/preferences.html)
> In the last major release, we unveiled [GitLab’s new navigation](/blog/2017/09/13/unveiling-gitlabs-new-navigation/).
> With GitLab 11.0, we think it’s a good time to introduce an additional set of new navigation
> themes! Five new user interface themes provide you with even more options to personalize your
> GitLab experience.
>
> Besides a fresh red theme, each theme received an additional light counterpart, allowing
> you to make a bold color statement!
[Squash and Merge in GitLab Core and GitLab.com Free](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html)
> When working on a large feature, developers often push multiple commits to a work-in-progress
> branch, and after code review, there may be even more commits to address various code
> issues. Before merging that branch to master, many teams
> prefer to squash all the commits into a single one, ensuring a [clean Git history](/blog/2018/06/07/keeping-git-commit-history-clean/),
> making it easier for folks in the future to review previous code changes.
>
> Squashing is a Git feature and a developer can do it right before merging on their local
> machine, but with squash and merge available directly in the GitLab web UI, you can
> do it with just a single click. For example, a repo maintainer merging-in the code
> can now do the squash without asking the code contributor to do so,
> saving one extra round-trip communication step.
>
> Squash and Merge, previously available in GitLab Starter, GitLab.com
> Bronze, and higher tiers, is now open source and available in GitLab Core
> and GitLab.com Free!
> Many users have said that all teams would benefit from this feature, and we are happy
> to bring it to everyone.
>
> Thank you [blackst0ne](https://gitlab.com/blackst0ne) for your contribution!
[Open projects in Xcode](https://docs.gitlab.com/ee/user/project/repository/index.html#open-in-xcode)
> At WWDC earlier this month,
> [Apple announced their Xcode integration with GitLab](/blog/2018/06/06/one-click-clone-to-xcode/),
> which makes it easier to work with your Xcode projects hosted in
> GitLab.
>
>
>
> [Assign ancestor group milestones](https://docs.gitlab.com/ee/user/project/milestones/)
> GitLab supports subgroups, and we have now leveraged that subgrouping structure for milestones. For any issue
> or merge request, you can now assign it a project milestone or a group milestone inherited from _any_ ancestor group.
>
> In particular, you can now have a high-level group with a set of milestones at that level.
> You can then use those _same_ milestones in any issues and merge requests in any subgroups deeper down, providing a powerful
> and flexible mechanism to organize work if you have nested groups and projects.
>
> Furthermore, you can filter by this milestone in group issue lists and group issue boards, so that you can pull
> in targeted objects from different levels in customized views.
[Issues and merge requests from subgroups in API](https://docs.gitlab.com/ee/api/)
> Subgroup support is also now consistent in the API when it comes to retrieving [issues](https://docs.gitlab.com/ee/api/issues.html#list-group-issues) and
> [merge requests](https://docs.gitlab.com/ee/api/merge_requests.html#list-group-merge-requests). That is,
> if you query a particular group through the API for issues and merge requests, you will get results
> from projects that are immediate children of that group, and also all from projects of all subgroups nesting down further.
> This is analogous to viewing the same objects in the web UI's group list views, which was introduced in recent prior releases.
[Persistent Auto DevOps deploy tokens for Kubernetes](https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy)
> Previously, when Auto DevOps was used for private or internal projects, the registry was
> not accessible by Kubernetes after the deploy job completed. This prevented
> the cluster from fetching the image again (for scaling, failures, etc).
>
> With GitLab 11.0, a new deploy token is created to provide persistent access
> to the registry when Auto DevOps is enabled on private/internal projects.
> This will ensure that the cluster can perform necessary operations and
> reduce possible failures.
[Specify deployment strategy from Auto DevOps settings](https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy)
> While some applications may benefit from deploying every change into
> production immediately after it's done, others may fare better by grouping
> those changes into a common environment for more thorough testing.
> Configuring different deployment strategies for different projects
> previously meant dealing with project-specific variables and then
> exercising them as needed.
>
> Starting in GitLab 11.0, Auto DevOps makes specifying your deployment
> strategy a single-click event. When enabling Auto DevOps for a specific
> project, you will be able to specify whether your application gets
> automatically deployed to production or deployed automatically to
> staging and then manually to production. This single-click configuration
> will allow you to spend more time working on your apps and less time
> configuring their deployment.
[Variables defining deployment policy for canary environments](https://docs.gitlab.com/ee/topics/autodevops/#deploy-policy-for-canary-environments)
> Oftentimes we'd like to roll out changes to a subset of users or servers to
> evaluate its impact before deploying across an entire environment. Previously,
> Auto DevOps users had to make the Auto DevOps template explicit and then
> define the desired behavior in order to achieve canary deployments.
>
> Starting with GitLab 11.0, users are able to define their canary policy
> by making use of the `CANARY_ENABLED` environment variable without the need to
> customize the Auto DevOps template, enabling faster canary policy
> declaration.
[Unmergeable merge request notifications and todos](https://docs.gitlab.com/ee/user/profile/notifications.html)
> Developers often work on multiple merge requests at a time, and it can be a challenge to keep track of them
> when many are open at once, awaiting collaborator reviews and feedback. Sometimes
> a merge request becomes unmergeable because of a conflict, perhaps caused by a change on the target branch.
> As a result, when you return to work on the merge request, you need to resolve the conflict.
>
> With this release, GitLab can now send you a [notification](https://docs.gitlab.com/ee/user/profile/notifications.html) and even
> assign you a [todo](https://docs.gitlab.com/ee/user/todos.html) if your
> merge request becomes unmergeable. You'll receive these as long as you are the author of the
> merge request, or have set it to be merged once the pipeline succeeds. This allows you to be
> proactive in fixing conflicts, or at least know what to expect when you revisit a merge request that
> you had worked on previously.
>
> **Note:** We originally missed mentioning this feature when this blog post was first published. This section has been added as of August 3, 2018.
[Fetch cluster parameters from GKE](https://docs.gitlab.com/ee/user/project/clusters/#adding-and-creating-a-new-gke-cluster-via-gitlab)
> Creating Kubernetes clusters in GitLab has never been easier. With GitLab 11.0,
> the "project" and "zones" values are automatically fetched from your Google
> Kubernetes Engine (GKE) account and displayed as a list for easy selection.
> Previously, creating a cluster using our GKE integration meant having to manually
> enter this data.
>
> Simple cluster creation will allow you to quickly stand up clusters from GitLab
> and quickly deploy your apps.
[Disable Auto DevOps jobs with variables](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables)
> When your application doesn't precisely fit one or more Auto DevOps stages, such as unit testing, code quality, etc., it is ideal to customize the pipeline to run only the jobs you care about.
>
> GitLab 11.0 now provides the ability to disable one or more Auto DevOps jobs through the use of environment variables. This allows you to take advantage of the power of Auto DevOps, even when your application doesn't fit with one of its stages.
[LFS files included when importing a project](https://docs.gitlab.com/ee/user/project/import/index.html)
> [Git LFS](https://docs.gitlab.com/ee/topics/git/lfs/index.html)
> helps to version large files with Git by storing them outside the
> repository and lazily downloading files at checkout rather than clone.
>
> When importing a project from GitHub, Bitbucket Cloud, or using a Git URL,
> GitLab now imports LFS objects so that you have a complete copy of the
> repository including those LFS objects. Previously, LFS objects were excluded
> from imports.
[Operations tab](https://docs.gitlab.com/ee/ci/)
> With the release of GitLab 11.0 we have added an **Operations** section in the navigation sidebar, making it quicker to access and easier to
> discover our operations features. In this release **Environments** and **Kubernetes** have been moved from **CI/CD** to **Operations**, and we will continue
> to add sections for features like Metrics and Logs in upcoming releases.
[Cloud-native GitLab Helm chart now Beta](https://docs.gitlab.com/charts/) (self-managed only)
> We are excited to announce that the cloud-native GitLab
> [Helm](https://helm.sh) chart is now in beta. This chart features a more cloud-native architecture,
> with a container for each component of GitLab and no requirement
> for shared storage. These changes result in increased resilience,
> scalability, and performance of GitLab on Kubernetes.
[Easily deploy and integrate JupyterHub with GitLab](https://docs.gitlab.com/ee/user/project/clusters/#installing-applications)
> [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user
> service for easily launching [notebooks](https://jupyter-notebook.readthedocs.io/en/latest/)
> across a data science team.
> Jupyter notebooks provide a web-based interactive programming environment commonly
> used for data analysis, simulation, visualization, and machine learning.
>
> GitLab 11.0 can now deploy JupyterHub to an integrated Kubernetes cluster
> with a single click, and it is automatically configured to use GitLab
> for seamless authentication. Additional options like [HTTPS](https://gitlab.com/gitlab-org/gitlab-ce/issues/47137),
> [group filtering](https://gitlab.com/gitlab-org/gitlab-ce/issues/47820), and [custom notebooks](https://gitlab.com/gitlab-org/gitlab-ce/issues/48236)
> will be added in future releases.
[Combined system note for successive issue description updates](https://docs.gitlab.com/ee/user/project/issues/)
> GitLab allows for powerful asynchronous collaboration and communication. With the ability
> to document ideas and have conversations in so many places, we encourage always maintaining
> a single source of truth in the description area of an issue or epic.
>
> This means that descriptions are often updated, many times in succession over a few minutes,
> leading to multiple system notes that say that the description has been updated. With this release,
> we are smartly combining those system notes if they happen within a short period of time,
> cleaning up the visual clutter and making comments in GitLab just a little bit easier to navigate. We'll
> be adding the same functionality to merge requests in the next release.
[Master role renamed to Maintainer](https://docs.gitlab.com/ee/user/permissions.html)
> At GitLab, we are [striving to build an inclusive culture](https://about.gitlab.com/handbook/values/#diversity-inclusion).
> And so even within GitLab the product, we're seeking ways to reflect that.
>
> We've decided to rename the Master role to the Maintainer role. It removes the negative connotations
> that may be associated with the term "Master," and at the same time, "Maintainer" is easily understood. Every
> small step helps, and we hope to move forward at GitLab, and together as an industry.
[Label lists redesign](https://docs.gitlab.com/ee/user/project/labels.html)
> Labels are a powerful mechanism in GitLab. As teams continue to create and use more labels,
> we want to ensure that managing them is easy. In this release, we've cleaned up the design
> of the label list pages, simplifying the interface, making it easier to consume information at
> a glance, and providing the UI affordances to quickly manage a particular label in further detail.
[Consistent naming format in issues API scope attribute](https://docs.gitlab.com/ee/api/issues.html)
> We made a small change in the issues API scope attribute to bring it in line with our consistent
> format of using snake case. The scope attribute now uses the values of `created_by_me` and `assigned_to_me`.
> You should use this format starting in GitLab 11.0 instead of the previous kebab-case (hyphenated) equivalents.
[Regex support for variables expressions](https://docs.gitlab.com/ee/ci/variables/#variables-expressions)
> In GitLab 10.7, we added support for variables expressions to `only` and `except` keywords.
> This allowed to define if a job should be created if a variable existed or had a specific value.
>
> With GitLab 11.0, we are extending this syntax to allow regex. Now you can create more flexible
> definitions based on a fine-grained pattern matching against the value. For example, you can skip
> a job based on the commit message.
[Get GitLab Runner IP address via the API](https://docs.gitlab.com/ee/api/runners.html#get-runner-s-details)
> In GitLab 10.6 we added the ability to see the IP address of a given GitLab Runner
> in the details view in the UI. This is very useful to better recognize, troubleshoot,
> and manage your infrastructure.
>
> With GitLab 11.0, we also expose this information in the API response so that it can
> be used by automated processes.
>
> Thank you [Lars Greiss](https://gitlab.com/lgreiss) for your contribution!
[GitLab Runner 11.0](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 11.0 today! GitLab Runner is the open source project
> that is used to run your CI/CD jobs and send the results back to GitLab.
>
> ##### Key changes in this release include:
>
> * [Add `--paused` option to register command](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/896)
> * [Change Prometheus metrics names](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/912)
> * [Start rename of "metrics server" config](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/838)
> * [Rename CI_COMMIT_REF to CI_COMMIT_SHA](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/911)
>
> The list of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.0.0/CHANGELOG.md).
[Improved deprecated configuration detection](https://docs.gitlab.com/omnibus/README.html) (self-managed only)
> Starting from GitLab 11.0, the Omnibus GitLab package will check for deprecated configuration in `gitlab.rb`, prior to starting an upgrade. In the event deprecated configuration settings are found,
> the package will abort the upgrade process prior to any changes. This allows the existing version to continue to run, while an administrator updates the problematic settings.
[Project-specific pipeline ID](https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables)
> When running CI/CD jobs for your project, sometimes you need a way to differentiate one execution
> from another. For this scope, you need a unique identifier that changes every time a new pipeline
> is created. This feature was already available through the `CI_PIPELINE_ID` environment variable,
> but this counter is unique for the entire GitLab instance and so it grows very fast, creating
> possible problems with long numbers.
>
> In GitLab 11.0 we are introducing another environment variable, `CI_PIPELINE_IID`, that contains
> a reference that is specific to the project. It means that it is incremented only when another
> run for the same project is created, keeping the value low and allowing developers to use it as
> part of the release process, for example as part of the version number.
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 11.0 includes [Mattermost 4.10](https://about.mattermost.com/releases/mattermost-4-10/), an [open source Slack-alternative](https://about.mattermost.com/) whose newest release includes Environment Variables Support in GitLab Omnibus, faster load times, ability to convert channels to private, plus much more.
> - Added a new flag, `master_on_initialization`, to control if a database node should report it itself as master. This flag should be disabled on secondaries.
> - Prometheus [rules can now be configured](https://docs.gitlab.com/omnibus/settings/prometheus.html#rules-files), providing the ability to add your own recording or alerting rules to the embedded Prometheus server.
> - The [PgBouncer exporter](https://docs.gitlab.com/ee/administration/monitoring/prometheus/pgbouncer_exporter.html) has now been added, providing insight into its health and operation.
> - `ruby` has been updated to 2.4.4. `git` has been updated to 2.17.1. `libpcre` has been updated to 10.31. `PgBouncer` has been updated to 1.8.1.
> - Let's Encrypt support has been added for the [Registry](https://docs.gitlab.com/omnibus/settings/ssl.html#registry) and [Mattermost](https://docs.gitlab.com/omnibus/settings/ssl.html#mattermost). When new certificates are requested, these hostnames will be added to the certificate.
[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.0)
> Some of the more noteworthy performance improvements in GitLab 11.0
> include:
>
> * [Searching issues within a group no longer times out on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/46648)
> * [Merge requests make fewer calls to access repository data](https://gitlab.com/gitlab-org/gitlab-ce/issues/45190)
> * [Notification emails run dramatically fewer SQL queries to calculate the recipients](https://gitlab.com/gitlab-org/gitlab-ce/issues/45534)
> * [Viewing a group page on GitLab.com no longer runs a query per subgroup to check access to Epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/6206)
> * [The LFS integrity check that takes place when pushing into a project that uses LFS is improved](https://gitlab.com/gitlab-org/gitlab-ce/issues/45062)
> * [Loading the projects API no longer preloads all of the authenticated user's membership records](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18945)
> * [Viewing a group page uses fewer queries to find projects, and a faster query to determine the open MR count](https://gitlab.com/gitlab-org/gitlab-ce/issues/43048)
> * [Deleting a group using the API now takes place in the background](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5505)
> * Many of the most commonly used APIs load significantly faster because of better preloading: [issues API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19345), [issues API again](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19269), [merge requests API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19346), [events API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19347), [jobs API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19353)
> * [Displaying a project's pipelines now requires fewer SQL queries](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18427)
> * We [upgraded Bootstrap 3 to 4](https://gitlab.com/gitlab-org/gitlab-ce/issues/45185) in preparation for our [GitLab UI Framework](https://gitlab.com/groups/gitlab-org/frontend/-/epics/1)