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:

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

[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.
#### [Premium](https://about.gitlab.com/pricing/premium/) ![6 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=6&style=flat-square "New features added to this tier in this release") ![86 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=86&style=flat-square "Total features in this tier")
[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)
#### Core ![26 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=26&style=flat-square "New features added to this tier in this release") ![328 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=328&style=flat-square "Total features in this tier")
[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)

To top