GitLab.org/GitLab: Release v11.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 11.2
Released: 2020-04-03
License: MIT
Release Assets:


#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)


[Todos for epics](https://docs.gitlab.com/ee/user/todos.html)
> Todos are a helpful personal productivity tool integrated directly into GitLab. When you
> are @-mentioned in an issue or merge request, you get a dismissible todo object in GitLab
> along with an email alert. And there are lots of other todo trigger events as well.
>
> With this release, we are bringing todos to epics, similar to their availability in issues and merge requests.
> When you are @-mentioned in an epic, you will get a todo for it, streamlining your personal workflows.
> You can also create a todo manually from the sidebar when viewing an epic itself, again similar to the capability within issues and merge requests.
>
> The API has also been updated so that you can access epic-triggered todos and
> create a todo for an epic, all via the API itself.
[Service level indicator alerts for custom metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics)
> GitLab includes a fully integrated performance monitoring solution, providing an easy and seamless
> way for engineers to view key metrics like throughput, error rate, and resource consumption. While it is
> critical to be able to view these metrics when needed, it is also important to be able to be proactively
> notified in the event of issues, to expedite a response.
>
> GitLab 11.2 now provides the ability to easily create alerts for custom metrics directly from the dashboard,
> with just a few clicks. Users can set the desired threshold, and when it's exceeded for five minutes, email notifications
> will be sent to maintainers and owners of the project. GitLab-provided metrics will be supported in a
> [future release](https://gitlab.com/gitlab-org/gitlab-ee/issues/6948).
[Approve and blacklist licenses](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)
> License Management automatically detects the software licenses that you
> are introducing with your code and its dependencies. In previous versions
> of GitLab, this feature kept you informed of all licenses, but did not
> allow you to define a policy about the licenses that should be allowed
> in your production code.
>
> With GitLab 11.2, you can now define whether any license should be approved
> or blacklisted for your application as soon as the relevant code is introduced
> in a merge request. The merge request widget displays all new licenses
> that have not yet been introduced into the target branch, and allows you
> to define whether each should be blocked or allowed, going forward.
[License Management reports at the pipeline level](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html#license-compliance-report-under-pipelines)
> Once a new change has been introduced into the codebase, users may want
> to know the updated set of licenses that apply to their application.
>
> GitLab 11.2 brings the License Management report to the pipeline level,
> so the current list of licenses can be accessed and users can check their
> master branch directly.
[Custom project templates on the instance level](https://docs.gitlab.com/ee/administration/custom_project_templates.html) (self-managed only)
> In today's fast-growing development environment, moving from an idea to
> setting up a new project from scratch is still a tedious task. There's not
> only a lot of boilerplate code involved, but also additional administrative
> overhead preventing your users from getting started right away.
>
> Starting with this release, we enable organizations to manage their own
> project templates. As a GitLab admin, you can now define a group within
> your installation that serves as source for custom templates. All direct
> child projects of this group are available as templates when creating a
> new project.
>
> All relevant repository and database information of a template are copied
> over to your new project, including the project and wiki repository, issues,
> project configuration, and more.
[Issue board milestone lists](https://docs.gitlab.com/ee/user/project/issue_board.html#milestone-lists)
> Issue boards were originally designed to support workflow tracking with label-based lists.
> In GitLab 11.0, we introduced [assignee lists](https://docs.gitlab.com/ee/user/project/issue_board.html#assignee-lists)
> to help teams see issues assigned to different team members and allow quick reassignments.
>
> With this release, we are introducing a third type of list, the milestone list. All issues
> assigned to the given milestone will appear in a milestone list. This allows teams to see
> issues in different milestones all at once in a single board with multiple milestone lists.
> This also means you can quickly move issues across different milestones.
> With the [summed weights](#summed-weights-in-issue-board-list) feature also in this release,
> this is especially useful for teams who want to balance total issue weight across milestones,
> not over-scoping or under-scoping in a given milestone.
>
> We've also updated the API so that you can now add and remove all three types of lists on
> a given board.
[Summed weights in issue board list](https://docs.gitlab.com/ee/user/project/issue_board.html#sum-of-issue-weights)
> Prior to this release, we already showed the issue counts at the top of each list in issue boards.
> This is helpful if you are doing any type of planning or tracking in an issue board, to see how
> many issues are in a particular workflow stage or assigned to a person in an assignee list.
>
> With this release, we are extending that concept to show the summed weights of all issues in each list
> alongside the issue count. This gives even more granularity to teams who use weights for effort
> estimation. You can now see at a glance how much weight is in a list, and if you need to move issues
> between lists to compensate for too much or too little weight, you can now do so and the summed
> weights will update immediately. You don't have to refresh the board.
[All burndown charts available in GitLab Starter and GitLab.com Bronze](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
> The burndown chart is a useful visualization for teams to track work as it is being completed
> during a milestone. It allows teams to anticipate risks early on, and make adjustments to mitigate them
> early in the cycle, rather than wait until the milestone is done.
>
> Previously, for the group milestone page, the burndown chart was only available in GitLab Premium and
> GitLab.com Silver. In this release, we've brought that feature to GitLab Starter and GitLab.com Bronze,
> allowing more users to enjoy group-based use cases. This also simplifies the feature, since the
> burndown chart on the project milestone page was already available with the Starter/Bronze tier.
[HTTP pull mirroring API](https://docs.gitlab.com/ee/api/projects.html#edit-project)
> Pull mirroring for HTTP remotes is now available through the Projects
> API. Pull mirroring makes it easy to keep forks and replicas up to
> date, regardless of whether the repositories are on the same server.
[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 noteworthy improvements in GitLab 11.2 include:
>
> * [Expose Geo project/file registry in the UI](https://gitlab.com/gitlab-org/gitlab-ee/issues/6851)
> * [Repository and wiki verification errors now available via API](https://gitlab.com/gitlab-org/gitlab-ee/issues/5594)
> * [Primary Geo node can now be removed from non-secondary instance states](https://gitlab.com/gitlab-org/gitlab-ee/issues/6265)
> * [Performance improvement for querying projects including wikis](https://gitlab.com/gitlab-org/gitlab-ee/issues/6064)
> * [Additional performance improvements and bug fixes](https://gitlab.com/groups/gitlab-org/-/boards/629512?milestone_title=11.2&=&label_name[]=Geo)
[Client-side evaluation in Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#live-preview)
> Working on web applications is faster and easier when it is possible to
> see your changes. Modern JavaScript frameworks now support live preview,
> eliminating the need to restart development servers and refresh the
> browser, but when editing these web applications using the Web IDE, it
> wasn't possible to see your changes before commiting them.
>
> In GitLab 11.2 you can preview your JavaScript web application in the
> Web IDE and see your changes in real time. This makes it possible to
> test a fix before you commit, quickly experiment with a change, or
> even contribute to an open source project without ever cloning it
> locally.
>
> Client-side evaluation is powered by
> [CodeSandbox](https://codesandbox.io). It can be enabled by an admin for
> self-managed GitLab instances and is already enabled for all projects on
> GitLab.com. Later this year we will add
> [server-side evaluation](https://gitlab.com/gitlab-org/gitlab-ee/issues/4013)
> powered by GitLab CI, allowing you to test and preview Ruby applications and more!
[Personal status messages](https://docs.gitlab.com/ee/user/profile/#current-status)
> Collaboration is a core principle within the GitLab product. When using GitLab day-to-day,
> together with your colleagues and community, it can be helpful to communicate what you are up
> to, including your availability or current workload.
>
> With GitLab 11.2, we are bringing status messages right to your personal profile!
> Within your profile settings, you can now add a status including an emoji and custom message.
> This status will show up on your profile page, as well as in comments and author titlebars, exposing your
> current status to everyone who is working with you.
>
> Thank you [Luke Niedermyer](https://gitlab.com/niedermyer) for your initial contribution!
[Improved top-navigation search](https://docs.gitlab.com/ee/user/search/#shortcut)
> As instances grow, projects and groups can multiply and become
> increasingly hard to find, so GitLab requires a powerful search experience.
> In this release, we're taking a step forward to make search clearer,
> more consistent, and easier than ever to use.
>
> In 11.2, we're improving search by removing project and group scoping from
> the search bar. Instead of restricting search to the project/group you're in,
> GitLab now gives you a consistent experience with the ability to search
> instance-wide from the top of every page.
>
> We've also made search easier to use by showing group and project icons
> in the results, plus expanding the width of the search bar accordingly.
[Support for Android project import](https://docs.gitlab.com/ee/user/project/import/manifest.html)
> Until now, importing complex project structures with multiple sub-structures was a tedious,
> time-consuming task.
>
> With this release, we introduce support for manifest files for project imports. A manifest
> XML file contains metadata for groups of repositories, allowing you to import larger project
> structures with multiple repositories in one go.
>
> When creating a new project, there is a new option to choose a "Manifest file" as source of
> your project import on the "Import project" tab. In addition, you can select from the list of
> individual projects in a subsequent step if you don't want to import the complete project
> structure.
>
> This improvement allows you to import the Android OS code from the
> [Android Open Source Project (AOSP)](https://source.android.com),
> as one exciting use case. You can also import other projects that use manifest files which meet our
> [format requirements](https://docs.gitlab.com/ee/user/project/import/manifest.html#manifest-format).
[Group milestones on dashboard milestones list page](https://docs.gitlab.com/ee/user/project/milestones/)
> Milestones in GitLab are useful for tracking work within an iteration or a sprint.
> In particular, group-level milestones allow issues across several different projects
> to be tracked together.
>
> With this release, we are showing group milestones on the dashboard milestones page.
> This means that users will now be able to see all milestones (both project and group
> milestones) that they have access to in the GitLab instance, all in a single location.
[Search labels in project labels list](https://docs.gitlab.com/ee/user/project/labels.html)
> Labels in GitLab are a versatile feature, allowing you to categorize issues, merge requests,
> and epics. Teams use them for a variety of use cases, and it's not uncommon for projects
> to have many pages of labels. As a result, it's often cumbersome to change a label name, its
> description, or its color. You have to click through many pages to get to the label you care about
> on the labels list page.
>
> In this release, we've made that easier by providing a search feature in the project labels list
> page itself. The search covers both the label title and description. So if you know the label title
> or even know just what the label is about, you can quickly find it by typing a search term in the text box.
[Multiple Jira transition IDs for closing Jira issues from GitLab](https://docs.gitlab.com/ee/integration/jira/)
> Many teams using GitLab also use Jira as an issue tracker. GitLab has a Jira
> integration that allows GitLab merge requests to automatically close a Jira
> issue when the merge request is merged. This requires you to configure a
> Jira transition ID in the GitLab settings, indicating how you want to transition
> Jira issues into the closed state. But this also means you are limited to
> only a single transition type on the Jira side.
>
> With this release, we now support multiple Jira transition IDs. That means if
> your Jira project is set up such that there are multiple ways to close a Jira issue,
> you can have GitLab recognize all those ways, so that merging a GitLab merge request
> will close the Jira issue, regardless of which state the Jira issue starts in.
>
> Thank you [lilinzhe](https://gitlab.com/slayercat) for the contribution!
[Cloud native GitLab Helm chart generally available](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 generally available (GA). 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. A [GitLab Runner](https://docs.gitlab.com/runner/) is also deployed,
> making it easy to get started with [GitLab CI/CD](https://docs.gitlab.com/ee/ci/).
>
> The `gitlab` chart is the best way to deploy GitLab on [Kubernetes](https://kubernetes.io/). Give it
> [a try](https://docs.gitlab.com/charts/) and [let us know](https://gitlab.com/charts/gitlab/issues) what you think!
[Importer for Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)
> While GitLab has supported importing projects from Bitbucket Cloud using OAuth authentication
> for quite some time, such an integration with the self-managed Bitbucket Server wasn't available.
> Until now.
>
> With GitLab 11.2, it is now possible to import your projects from Bitbucket Server to GitLab
> with minimal effort. All that is required is to provide the server URL and your credentials.
> GitLab then lists all your Bitbucket Server repositories, ready for import.
[Private profiles](https://docs.gitlab.com/ee/user/profile/#private-profile)
> The user profile page on GitLab shows your activity, contributions, and personal projects.
> While visitors only see detailed activity that they have permission to see,
> such as your comments on public repositories, some users may prefer not to expose this information
> in aggregate.
>
> With GitLab 11.2, we introduce the option to disable activity-related information on your
> profile, giving you more complete control over the information you share with the community.
>
> Thank you [JX Terry](https://gitlab.com/jxterry) for your [MVP-winning](#mvp) contribution!
[Show project ID on project overview](https://docs.gitlab.com/ee/user/project/)
> GitLab projects are associated with an auto-generated, unique project ID upon creation. This
> information is available in the General project settings and via our API.
>
> With this release, we have added the project ID to the project overview page,
> so that users without Maintainer permissions also have access to this ID when needed.
>
> Thank you [Tuğçe Nur Taş](https://gitlab.com/nuritnt) for this contribution!
[Download individual repository files](https://docs.gitlab.com/ee/user/project/repository/)
> When browsing through a project repository on GitLab, the need to download
> a specific file frequently arises. Until now, this was only possible within
> the GitLab interface by viewing the file in a new browser tab
> and then saving it.
>
> GitLab 11.2 introduces a new "Download" button in the file viewer interface,
> available for each individual repository file, allowing you to
> download any file directly from the application more easily.
>
> Thank you [Kia Mei Somabes](https://gitlab.com/kia1) for your contribution!
[Google Hangouts integration](https://docs.gitlab.com/ee/user/project/integrations/hangouts_chat.html)
> Chat applications work great together with GitLab, as a complementary way for teams
> to communicate and get work done. In this release, we're happy to merge
> in a generous contribution from Kukovskii Vladimir to integrate Google Hangouts
> into GitLab. With this feature configured as a project service, you can now
> receive a variety of GitLab events as notifications directly within Hangouts.
>
> Thank you to [Kukovskii Vladimir](https://gitlab.com/enzinia) for the contribution!
[Support for Git SSH access via certificates](https://docs.gitlab.com/ee/administration/operations/ssh_certificates.html) (self-managed only)
> In large organizations, SSH keys may only be issued on a temporary basis
> and be set to expire quickly. An alternative approach, available with
> GitLab 11.2, is to use OpenSSH certificates which include all the information
> about the user within the certificate. This removes the need for users
> to generate and upload SSH keys.
>
> Thank you [Ævar Arnfjörð Bjarmason](https://gitlab.com/avar) for your contribution!
[Instance-level analytics available for everyone](https://docs.gitlab.com/ee/user/instance_statistics) (self-managed only)
> Analytics are an important tool for understanding activity on your GitLab instance.
> Previously, two of these features – ConvDev Index and Cohorts – have
> only been visible to admins.
>
> Since these features provide useful (and anonymized) information on GitLab
> usage, we are making them visible to all users, by default, behind a new
> "Instance Statistics" section in the top navigation bar.
> Visibility of this section is configurable, and can be set to admin-only.
>
> Introducing instance-level statistics is our first step to democratize
> analytics in GitLab, and we are excited to introduce more to this section
> in the future.
[Custom Wiki sidebar](https://docs.gitlab.com/ee/user/project/wiki/#customizing-sidebar)
> When utilizing a Wiki in your GitLab project for extended documentation, the right sidebar shows
> a hierarchical table of contents of your Wiki page structure by default. There are cases, however,
> where you may want to provide additional content, extending this set of automatically listed pages.
>
> With GitLab 11.2, we introduce an option to override the generated table of contents via your
> own custom sidebar. By adding a `_sidebar` Wiki page, maintainers gain full freedom to define an
> individual Wiki sidebar based on [GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm).
>
> Thank you [jsooter](https://gitlab.com/jsooter) for your contribution!
[Securely build Docker images with kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html)
> Historically, building Docker images within a containerized environment has required compromises, using techniques
> like [docker-in-docker](https://blog.docker.com/2013/09/docker-can-now-run-within-docker/) on
> [privileged containers](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).
> These solutions are often insecure and slow.
>
> [kaniko](https://cloudplatform.googleblog.com/2018/04/introducing-kaniko-Build-container-images-in-Kubernetes-and-Google-Container-Builder-even-without-root-access.html)
> is a new tool developed by Google, which is able to securely build an image within an unprivileged container.
> GitLab 11.2 and Runner 11.2 are now [compatible](https://gitlab.com/gitlab-org/gitlab-ce/issues/45512) with kaniko,
> enabling usage with [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) and the integrated
> [Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html).
[Delete and rename files in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/)
> The Web IDE is the most convenient way to add and edit files in the GitLab
> interface, but renaming and deleting existing files was not yet possible. In this
> release, you can now delete and rename any file without leaving the Web IDE.
[Switch branches in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#switching-branches)
> In GitLab 11.2 you can now switch to any branch in the current
> repository without leaving the Web IDE. The improved branch and merge
> request switcher allows you to search the list of branches for the
> current repository.
[JUnit test summaries in merge request widget](https://docs.gitlab.com/ee/ci/unit_test_reports.html)
> It is very common for a pipeline to contain a test job that checks the latest code. If the tests fail,
> the pipeline fails and users are notified. But they still want to dig into details about the
> failed tests.
>
> With the 11.2 release, it is now possible to see JUnit test results directly in the
> merge request widget.
[Built-in project templates now use Dockerfile](https://docs.gitlab.com/ee/user/project/working_with_projects.html#built-in-templates)
> Our built-in project templates are now built using Dockerfiles instead of herokuish. For some
> configurations this will result in performance improvement of build times, and is considered
> a best practice that we want to illustrate in our templates.
[Mutual SSL authorization for Helm Tiller](https://docs.gitlab.com/charts/installation/tools.html)
> In order to improve the security of Kubernetes clusters integrated with GitLab,
> we must ensure Helm Tiller is secured so that only the GitLab instance managing it
> can deploy applications to its namespace.
>
> Starting in GitLab 11.2, all new Helm Tiller applications that are deployed to
> Kubernetes clusters via GitLab's Kubernetes integration will be locked down using
> mutual SSL authentication. This means no other clients outside of your GitLab instance
> will be able to deploy applications, making your cluster more secure. Additionally, starting
> with this release, we will be using Helm Tiller version 2.7.2.
[Ability to manually stop an environment](https://docs.gitlab.com/ee/ci/environments/index.html#stopping-an-environment)
> Some CI/CD environments are disposable and unlikely to be reused in the future. One
> clear example is when using [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/),
> where a new environment is created dynamically on each branch. Up until
> now, you could only stop an environment if you
> [defined it in `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/#environmenton_stop). With
> GitLab 11.2, it is now possible to manually "stop" an environment from the UI
> under the environments page.
[GitLab Runner 11.2](https://docs.gitlab.com/runner)
> We are releasing GitLab Runner 11.2 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:
>
> * [Add `artifact` format and support for multiple artifacts per job](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/923)
> * [Fix support for Unicode variable values when Windows+PowerShell are used](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/960)
> * [Set User-Agent in Kubernetes API calls](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/977)
> * [Add BusyBox shell](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/900)
>
> A list of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.2.0/CHANGELOG.md).
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 11.2 includes [Mattermost 5.1](https://mattermost.com/blog/mattermost-5-1-new-gif-selector-auto-linking-plugin-subpath-support-and-more/),
> an [open source Slack-alternative](https://mattermost.com/) whose newest release includes a new GIF selector, auto-linking plugin,
> subpath support, plus much more. Since it includes [security updates](https://about.mattermost.com/security-updates/), upgrading is recommended.
> - `gitlab-ctl repmgr` now honors the directories set by `postgresql['data_dir']`.
> - GitLab's Prometheus instrumentation now works out of the box on Docker containers.
> - `git` has been updated to 2.18.0.
> - Alertmanager has been updated to 0.15.1, gitlab-monitor has been updated to 2.18.0.
[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.2)
> Some of the more noteworthy performance improvements in GitLab 11.2 include:
>
> * [Improved API query performance for /groups/:name](https://gitlab.com/gitlab-org/gitlab-ce/issues/42415)
> * [Resolved strain on users table due to UserActivity workers](https://gitlab.com/gitlab-org/gitlab-ce/issues/43312)
> * [Project and namespace routes are no longer created dynamically](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20313)
> * [Optimized Wikis by rendering only the Markdown of the current page](https://gitlab.com/gitlab-org/gitlab-ce/issues/45860)
> * [Old merge requests make fewer Gitaly calls](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21053)
> * [Expanding collapsed diffs on merge requests is more efficient](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20940)
> * [Decreased memory footprint in Changes tab on merge requests page](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21028)
> * [GPG commit signatures are extracted in bulk when new commits are pushed](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20870)