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

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

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

[Epic forecasting with integrated milestone dates](https://docs.gitlab.com/ee/user/group/epics/)

> Prior to this release, you could set fixed values for the planned start > date and the planned end date of an epic. This is useful for high-level > planning of epics, and tracking them over time. However, as issues are > attached to the epic, and the issues are scheduled for work with actual > milestones, it would be useful to have the epic dates reflect those milestones. > > With this release, you can easily switch from the fixed value for either of > the dates, to a dynamic value called `From milestones`. For the planned > start date, this dynamic value will take on the earliest start date of all > milestones assigned to the epic's attached issues. This is truly dynamic > in that it will change if issues are added or removed, if milestones are > assigned or unassigned (to those issues), or if the start dates are changed > for those milestones. The dynamic version of the epic's planned end date > is analogous. > > This feature is useful if you want to seamlessly transition from high-level, > top-down planning to micro-level, bottom-up planning. See more in a > [blog post on the Epics roadmap](/blog/2018/08/23/epics-roadmap/) that we published > about this a few weeks back.

[New epic event as custom notification](https://docs.gitlab.com/ee/user/profile/notifications.html)

> In a previous release, we provided email notifications for new epics, > for users who have configured their group-level notifications to the > `Watch` level. With this release, we are adding more customization. > You can now configure this event trigger on or off using the `Custom` notification > level, along with other event triggers.

[Quick action to add issue to epic (from issues)](https://docs.gitlab.com/ee/user/project/quick_actions.html)

> Adding an issue to an epic (or removing an already attached issue) is easily > done from the epic page itself. This is useful for when you are already > working in an epic. > > But sometimes you are working in an issue, and know that you want to attach > it to an existing epic that you know about. You can now do so with a simple quick > action on the issue page by pasting in the epic URL. In a future release, > you'll even be able to [search for the epic in the quick action command via > autocomplete](https://gitlab.com/gitlab-org/gitlab-ee/issues/7473). > > Additionally, another issue quick action will allow you to remove it from > an already attached epic.

[SAST support for Groovy](https://docs.gitlab.com/ee/user/application_security/sast/)

> Static Application Security Testing is responsible for spotting vulnerabilities in your > source code as soon as it is committed to the repository, looking for known patterns > and common errors that may lead to security flaws in the final application. > That's why each different language needs specific support. > > With GitLab 11.3, we introduce [Groovy](https://en.wikipedia.org/wiki/Apache_Groovy) > in the list of languages supported by GitLab SAST. Projects using this language are > now automatically detected and you don't need to change anything to your code or your > pipeline definition to enable this feature. Auto DevOps is also supporting it as part > of its default configuration.

[Alerts for library metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics)

> In GitLab 11.2, we added the ability to set alerts for [custom metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics), which allowed developers to be notified > in the event of any issues with their applications. > > With GitLab 11.3, we have now extended support for alerts to all metrics, including the metrics that > are provided by default with our [library metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/index.html).

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

[Maven repository](https://docs.gitlab.com/ee/user/packages/maven_repository/index.html)

> For any development organization, having an easy and secure way to manage > dependencies is critical. Package management tools, such as Maven for Java developers, provide > a standardized way to share and version control these libraries across projects. > > In GitLab 11.3, we are proud to offer Maven repositories built directly into GitLab. Developers of > lower-level services can now publish their packaged libraries to their project's Maven repository. > They can then share a simple XML snippet with other teams looking to utilize that library, > and Maven and GitLab will do the rest. > > Check out a [sample project](https://gitlab.com/gitlab-org/examples/mvn-example) which builds and > pushes to the GitLab Maven repository, and see how easy it is!

[Improve includes in .gitlab-ci.yml for reusing scripts](https://docs.gitlab.com/ee/ci/yaml/#extends)

> Reusing CI/CD process code is a great practice to help ensure > consistency in software delivery, and minimizes the amount of per-job > scripting that's needed to write and maintain. We now offer a flexible, > powerful approach for code reuse in templates using YAML `extends` > keywords.

[Protected Environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)

> Operators are often responsible for the sensitive task of protecting the environments we > deploy code to on a daily basis. This task becomes particularly important when deploying > code to a production environment. > > With Protected Environments, operators obtain full control around which person, group, or account > is allowed to deploy to a given environment, allowing further protection and safety of sensitive > environments.

[Code Owners](https://docs.gitlab.com/ee/user/project/codeowners/)

> Code review is an essential practice of every successful project, but > who should review the changes is not always clear. GitLab now supports > assigning code owners to files to indicate the team members responsible > for code in your project. > > Code owners are assigned using a file named `CODEOWNERS`, a format > similar to [`gitattributes`](https://git-scm.com/docs/gitattributes), > and are listed below the commit details when viewing a file in GitLab. > > In upcoming releases, Code Owners will be integrated into the merge > request workflow to > [suggest approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/5382), > [assign approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/1012), > and [enforce code owners](https://gitlab.com/gitlab-org/gitlab-ee/issues/4418).

[Allow self-approval of merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#allowing-merge-request-authors-to-approve-their-own-merge-requests)

> The user who creates a merge request may not be the author of the > changes, and other users may add additional changes to the merge > request after it is opened. Maintainers can now allow self-approval > of merge requests from the project settings. > > Previously, the user who opened the merge request was assumed to > implicitly approve the merge request and was therefore excluded from > approving the merge request. There are many situations where this is > not true. Allowing self-approval removes this assumption.

[Custom file templates for self-managed instances](https://docs.gitlab.com/ee/administration/settings/instance_template_repository.html) (self-managed only)

> File templates for `LICENSE`, `.gitignore`, `Dockerfile` and > `.gitlab-ci.yml` files make it easy to add these common files to > projects. Custom file templates can now be added to self-managed GitLab > instances by selecting an instance-wide template repository which > contains your templates. > > Custom templates are useful when the templates provided by GitLab are > too generic, for example a custom license that should be used for every > project in the company, or a complex `Dockerfile` that should be used > for every microservice. > > Thank you [Daniel Barker](https://gitlab.com/barkerd427) for > contributing > [custom license templates](https://gitlab.com/gitlab-org/gitlab-ee/issues/5986).

[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.3 include: > > - [`git fetch` and `git push` operations on secondary Geo nodes are now automatically redirected to the primary node when using SSH](https://gitlab.com/gitlab-org/gitlab-ee/issues/6533) > - [Disabled project wikis are now synced correctly](https://gitlab.com/gitlab-org/gitlab-ee/issues/6142) > - [Checksum progress on Geo Admin Area page is now reflecting correct percentage states](https://gitlab.com/gitlab-org/gitlab-ee/issues/6028) > - [Update events from fork merge requests are now generated correctly](https://gitlab.com/gitlab-org/gitlab-ee/issues/7245) > > You can also read about [how we built GitLab Geo](/blog/2018/09/14/how-we-built-gitlab-geo/).

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

[Interactive web terminals for Shell and Kubernetes Runners](https://docs.gitlab.com/ee/ci/interactive_web_terminal/)

> CI/CD jobs are executed by runners based on the configuration provided > by users in their pipeline definition. But this execution is not > interactive and, if it fails, users cannot dig into details to > spot the possible source of the problem. Interactive web terminals > bring the capability to connect to a running or completed job and > manually run commands to better understand what's happening in the > system.

[Include private contributions in user contribution graph](https://docs.gitlab.com/ee/user/profile/#private-contributions)

> At GitLab, we love open source! But sometimes you want to work on a private project you don't > want to share (yet), or you are constrained for confidentiality reasons. In any case, GitLab has > got you covered. > > With this release, we are introducing the option to include private contributions in your > profile's contribution graph. Contributions to private projects are now displayed in the > contribution graph and contributions of this day if you enable this setting for your profile. > This way, your active work on private GitLab projects is represented accurately, without > giving away any private details. > > Thank you [George Tsiolis](https://gitlab.com/gtsiolis) for your contribution!

[Redesigned project overview](https://docs.gitlab.com/ee/user/project/)

> Iterating on our user interface is a constant focus for improving our product. > > With GitLab 11.3, we are updating the UI of the project overview page to allow for a better > experience when exploring projects. Besides improving the overall information structure of > this page, we are left-aligning the top header section and optimizing the vertical spacing, so > you can get a quicker overview about the project and its content.

[Display repository languages on project overview](https://docs.gitlab.com/ee/user/project)

> The code languages of which a repository consists is relevant information when exploring GitLab > projects. > > With this release, we are adding a code languages bar to the project overview, showing all > relevant languages the repository consists of, including their relative quantity.

[File templates in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/)

> File templates for `LICENSE`, `.gitignore`, `Dockerfile` and > `.gitlab-ci.yml` make it easy to add these common files to projects, > and can now be used in the Web IDE. File templates in the Web IDE makes > it easier to start a new project in the Web IDE and keep these > important files up to date.

[Define project name when creating a new project](https://docs.gitlab.com/ee/user/project/#new-project)

> To add a project name to your newly created GitLab project, you previously had to go into the > project settings and overwrite the project slug with a proper name. > > With GitLab 11.3, we are adding the project name field to the "Create project" form. In addition, > the project slug is now automatically generated from the project name, while still allowing > you to adjust this field. This improvement makes the process of creating a new project faster > and more straightforward.

[Store Wiki uploads in the Wiki repository](https://docs.gitlab.com/ee/user/project/wiki/)

> Images uploaded to the wiki through the wiki editor are now stored in > the Git repository. This means images will now be display when > previewing a wiki locally using [Gollum](https://github.com/gollum/gollum). > > Previously, images were stored in the project uploads directory with > attachments uploaded to issues and merge requests. This prevented wikis > from being previewed locally or being migrated to a different Git > repository.

[Filter webhook push events by branch](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html)

> Webhooks for push events make it easy to automatically notify external > services of new commits, but all branches are rarely of equal > importance. Push events can now be filtered by branch so that > external services are only notified about the changes that matter to > you. > > Previously webhooks could not be filtered by GitLab, and most external > systems do not have a feature filter incoming events. This meant it was > not possible to integrate these services directly with GitLab if you > only wanted a subset of push events to be used by the external service. > > Thank you [Duana Saskia](https://gitlab.com/starkcoffee) for your > contribution!

[Auto DevOps enabled by default](https://docs.gitlab.com/ee/topics/autodevops/)

> Auto DevOps was made generally available in GitLab’s 11.0 release and while it has > had great adoption, we want all GitLab users to take advantage of its great features. > From Auto Build to Auto Monitoring, Auto DevOps brings valuable benefits out of the box. > > Starting with GitLab 11.3, Auto DevOps will be enabled by default on both GitLab.com and on > self-managed instances, so that every project can take advantage of its features. > > Read through the documentation on [enabling/disabling Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops) if you wish to disable it for your project or for an entire instance.

[Automatically disable Auto DevOps for project upon first pipeline failure](https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops)

> At GitLab, one of our product values is to [default to on](/handbook/product/product-principles/#configuration-principles). > When we introduce a new configurable feature we know to be of great value, we will > default to ON so that everyone can benefit from it. While Auto DevOps supports > projects using the most popular programming languages, there may be some specialized > projects for which additional configuration is required. > > Because we want to ensure we will not be running Auto DevOps pipelines for projects > that are not supported, we will disable Auto DevOps automatically if one of its pipelines fails. > GitLab will notify the project owner of this attempt so they can make the necessary > configuration changes to work with Auto DevOps if desired. Once the necessary changes are made, > project owners can re-enable Auto DevOps.

[Gitaly v1.0](/blog/2018/09/12/the-road-to-gitaly-1-0/)

> Git access for regular usage of GitLab can now occur entirely through > Gitaly, GitLab's gRPC service to access Git. This means it is possible > to run Gitaly on its own server without NFS when all optional feature > flags are enabled. > > In the upcoming [Gitaly v1.1](https://gitlab.com/groups/gitlab-org/-/epics/288) > release all feature flags will be enabled by default, and the last > few remaining features will use Gitaly, removing the need for NFS. > > Read our blog post about > [the road to Gitaly v1.0](/blog/2018/09/12/the-road-to-gitaly-1-0/).

List of open source software components used by GitLab now available online

> Starting with GitLab 11.3, we are making the list of open source software used by > GitLab more easily available. Prior to this release, it was available in each of our > Linux packages, but that required downloading and extracting the contents. > > We are now publishing this content online, so it is easier to access and link to. > The list is available for [GitLab CE](https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab-ce.html) and [GitLab EE](https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab-ee.html).

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

> We're also releasing GitLab Runner 11.3 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 initial support for CI Web Terminal](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/934) > - [Introduce GCS adapter for remote cache](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/968) > - [Update Docker images to `alpine:3.8`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/984) > - [Make configuration of helper image more dynamic](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1005) > - [Fix incorrectly generated `Content-Range` header for `PATCH /api/v4/jobs/:id/trace` request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/906) > - [Fix HTTPS validation problem when ssh executor is used](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/962) > > A list of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.3.0/CHANGELOG.md).

[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.3)

> Some of the more noteworthy performance improvements in GitLab 11.3 include: > > - [Speed up first load of a newly created merge request by highlighting and caching diffs in the background upon creation](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21489) > - [Speed up loading of 'Last commit' column in tree views by performing Markdown rendering of commit titles in bulk](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21500)

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

> - GitLab 11.3 includes [Mattermost 5.2](https://mattermost.com/blog/mattermost-5-2-upgraded-plugin-system-search-archived-channels-romanian-language-support-and-more/), > an [open source Slack-alternative](https://mattermost.com/) which includes an > upgraded plugin system, ability to search archived channels, Romanian language > support, and much more. Since it includes > [security updates](https://about.mattermost.com/security-updates/), upgrading is recommended. > - `gitlab-elasticsearch-indexer` has been updated to 0.2.2. > - `omnibus-ctl` has been updated to 0.6.0. > - The Redis [tcp_backlog](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) and > [HZ](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L823) > settings are now configurable, as well as > [max_concurrency](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L1600) > in sidekiq_cluster. > - The default maximum memory Sidekiq can use is now 2GB. > - SSL compression has been disabled by default for `gitlab-psql` and `gitlab-geo-psql`.