GitLab.org/GitLab: Release v11.7.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 11.7
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)
[Multi-level Child Epics](https://docs.gitlab.com/ee/user/group/epics/)
> Epics and issues work great together to provide flexibility in defining
> longer-term work plans. However, they are still limited to providing
> only a two-layer structure.
>
> With this release, we are introducing Child Epics. You can now have an
> epic containing both issues and epics. This allows you to create
> multi-level work breakdown structures. So you can now represent even
> longer-term strategic initiatives or organization goals as high-level
> epics, and then have multiple levels of epics below those to break them
> down into more tangible deliverables, all the way down to issues.
[Remediate vulnerability with patch file](https://docs.gitlab.com/ee/user/project/merge_requests/#solutions-for-dependency-scanning-ultimate)
> GitLab can detect different types of vulnerabilities in your apps, and also suggest a possible
> remediation to fix them.
>
> Starting with GitLab 11.7, you can download a patch file, and apply it to your repo using the
> `git apply` command. Then you can push changes back to your repository, and the [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/index.html)
> will confirm if the vulnerability is gone!
> This makes the resolution process very easy and reduces the time needed to deploy a solution.
> Currently, Dependency Scanning vulnerabilities for the `yarn` package manager are supported, and
> you don't need to change anything to make it work. The patch will be available, every time it is
> possible, in the vulnerability details window.
[Filter vulnerabilities in the Group Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#viewing-the-vulnerabilities)
> The Group Security Dashboard allows security teams to keep everything under control
> by showing vulnerabilities that affect their groups.
>
> With GitLab 11.7, users can filter displayed vulnerabilities by severity, report type,
> and project name. With this ability, they can focus on what they need and reach their
> data faster, especially useful when there are many entries in the list.
[Show Dependency Scanning results in the Group Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#supported-features)
> The Group Security Dashboard was initially released with [SAST](https://docs.gitlab.com/ee/user/application_security/sast/)
> results only, so users were not able to manage other types of vulnerabilities with this feature.
>
> With GitLab 11.7, [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
> findings have been added to the set of available data.
> If you are already using the [new report syntax](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportsdependency_scanning),
> you will automatically see results in the dashboard.
> The [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) template has been
> updated as well, and it now requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above
> to run the Dependency Scanning job correctly.
[Search filter box for issue board navigation](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards-starter)
> Teams often use many issue boards in a given project or board, making
> the dropdown navigation difficult to use if the list is very long. With
> this release, we are introducing a search filter. Simply type a few characters
> in the search filter box to quickly narrow down to the issue board you are
> interested in, making navigation much easier.
[Stricter self-approval restrictions](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#eligible-approvers)
> Code review is an essential practice of every successful project, and
> should be conducted by someone who isn't the author of the change. By
> default, self approval of merge requests is not permitted, but was
> prevented based on the author of the merge request, not the commits in
> the merge request.
>
> From GitLab 11.7, self-approval restrictions also prevent people who
> have committed changes to the merge request from approving, so that
> merge requests authored by multiple engineers receive fully independent
> code reviews and approvals.
[Cross-project pipeline browsing](https://docs.gitlab.com/ee/ci/pipelines/index.html#pipeline-graphs)
> It is now possible to expand upstream or downstream cross-project pipelines right from the
> pipeline view, giving you visibility into your end-to-end pipelines, no matter in which project
> they start or finish.
[NPM registry](https://docs.gitlab.com/ee/user/packages/npm_registry/index.html)
> JavaScript developers need a secure, standardized way to share and version control NPM packages across projects. An NPM registry offers developers of lower-level services a way to publish their code in such a way.
>
> In GitLab 11.7, we are proud to offer NPM registries built directly into GitLab. This being integrated right into GitLab would mean they can then share a simple package-naming convention to utilize that library in any Node.js project, and NPM and GitLab will do the rest, all from a single interface. This feature is available with GitLab Premium.
>
> Check out a [sample project](https://gitlab.com/gitlab-org/examples/npm-publish) which builds and pushes to the GitLab NPM registry, and see how easy it is!
[Publish releases for your projects](https://docs.gitlab.com/ee/user/project/releases/index.html)
> Our new Releases feature adds the ability to create releases in GitLab and view them on a summary page. Releases are
> a snapshot in time of the source, links, and other metadata or artifacts associated with a
> released version of your code, and allow for users of your project to easily discover the latest released
> version of your code.
[Configure Kubernetes app secrets as variables for Auto DevOps pipelines](https://docs.gitlab.com/ee/topics/autodevops/#application-secret-variables)
> Operators and administrators require that the configuration of secrets takes place outside the application's repository to
> reduce risk and exposure of sensitive data. To address this need, GitLab now offers the ability to configure
> secrets as environment variables that are made available to the Auto DevOps application running in your Kubernetes cluster.
>
> Simply prepend your variable with `K8S_SECRET_` and the relevant Auto DevOps CI pipeline will take your application
> secret variable to populate a Kubernetes secret.
[API support for Kubernetes integration](https://docs.gitlab.com/ee/api/project_clusters.html)
> With this release, we have brought API support to our Kubernetes integration. This means that all the actions
> currently available in the GUI, such as listing, adding, and deleting a Kubernetes cluster are now accessible
> via the API. Teams can use this new functionality to fold in cluster creation as part of their workflow.
[Project list redesign](https://docs.gitlab.com/ee/user/project/)
> Projects are first-class citizens in GitLab, and we want to make project
> lists visually pleasing and easy to parse.
>
> In GitLab 11.7, we introduced a redesign of the project list UI that focuses
> on readability and a summary of the project's activity. We've given each
> project row additional project information and whitespace, and will
> [continue to iterate](https://gitlab.com/gitlab-org/gitlab-ce/issues/55669)
> on the design based on feedback.
[RBAC mode default for Kubernetes cluster creation](https://docs.gitlab.com/ee/user/project/clusters/#role-based-access-control-rbac)
> Securing your Kubernetes cluster is vital in order to control and limit who can access the cluster
> and what actions they are allowed to perform.
>
> Starting with GitLab 11.7, all clusters will default to RBAC-enabled at time of creation, providing more secure and
> protected infrastructure.
[GitLab Runner 11.7](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 11.7 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:
>
> - [Kill Web Terminal session when build is canceled](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1058)
> - [Fix path separator for CI_PROJECT_DIR in Windows](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1128)
>
> List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.7.0/CHANGELOG.md).
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 11.7 includes [Mattermost 5.6](https://mattermost.com/blog/mattermost-5-6-interactive-message-dialogs-new-admin-tools-ukrainian-language-support-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes interactive message dialogs, new admin tools, Ukrainian language support, and much more.
> - [Enhanced Networking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) support is now available for the [official GitLab AMI images](https://docs.gitlab.com/ee/install/aws/#choose-the-ami), allowing for additional instance types to be utilized, as well as increased bandwidth.
[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.7)
> We continue to improve the performance of GitLab with every release,
> for GitLab instances of every size.
>
> In GitLab 11.7, we have significantly improved the performance of
> viewing merge requests by [caching syntax highlighted discussion
> diffs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23857).
>
> Other noteworthy performance improvements include:
>
> - [Improve push performance by skipping pre-commit validations that have passed on other branches](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23984)
> - [Remove redundant counts in snippets search](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23952)
> - [Speed up Open board list when there are assignee lists](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9090)
[Support catch-all email mailboxes including Microsoft Exchange and Google Groups for incoming email features](https://docs.gitlab.com/ee/administration/incoming_email.html)
> GitLab has some great features that use incoming email, such as [reply by email](https://docs.gitlab.com/ee/administration/reply_by_email.html),
> [new issue by email](https://docs.gitlab.com/ee/user/project/issues/create_issues.html#by-sending-an-email),
> [new merge request by email](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#create-new-merge-requests-by-email),
> and [service desk](https://docs.gitlab.com/ee/user/project/service_desk.html).
> Previously, you could only take advantage of these features if you used an email
> server configured to use sub-addressing.
>
> With this release, GitLab now supports both sub-addressing and catch-all
> email mailboxes, using a new email format, allowing more email servers to
> be used with GitLab, including Microsoft Exchange and Google Groups (which
> do not support sub-addressing).
[Import issues CSV](https://docs.gitlab.com/ee/user/project/issues/csv_import.html)
> Often when teams start using GitLab, they may be using different tools and have legacy data.
> You may be currently using Jira but would like to move to GitLab issues.
>
> With this release, we are making this transition easier. Since many issue
> tracking systems allow for a CSV export, you can now import such an export
> of issues into GitLab, allowing you to continue managing your existing
> work, importing legacy data into GitLab for future search and retrieval
> as necessary. This will work with Jira or any issue tracking system that
> can generate a CSV export.
>
> GitLab also has an existing [CSV export feature](https://docs.gitlab.com/ee/user/project/issues/csv_export.html)
> too.
[Support for private Go packages in subgroups](https://docs.gitlab.com/ee/user/group/subgroups/)
> Go packages hosted in GitLab can be installed using `go get`, however
> this was not supported for private projects in subgroups. Starting with
> GitLab 11.7, any project can be used as a Go package, including private
> projects in subgroups.
>
> Private packages are supported by the `go get` command using a `.netrc`
> file, and using a personal access token in the `password` field.
>
> Thank you [MortyChoi](https://gitlab.com/mortyccp) for the
> contribution!
[Short commit SHA available as environment variable](https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables)
> Git SHAs are 40-character pointers to specific objects (i.e., commits) in a Git repo. Often, showing the full string
> is unwieldy and you just want to show the first eight characters as a quick (though not guaranteed unique)
> reference. We've added the `CI_COMMIT_SHORT_SHA` environment variable to the CI pipeline for this purpose,
> which will give you the first part of the commit SHA being built.
[Authorization support for fetching includes](https://docs.gitlab.com/ee/ci/yaml/#include)
> When including external files in your pipeline definition using the `include` keyword, these are fetched using
> HTTP/HTTPS requests. You are now able to access yamls on another project with no public access (e.g.,
> a private project on GitLab.com) using the credentials the pipeline is running as.
[Include CI/CD files from other projects and templates](https://docs.gitlab.com/ee/ci/yaml/#include)
> The `include` keyword allows users to create CI/CD pipelines dynamically, with
> external files included into the configuration. This was previously possible
> only for files in the project repository, or for remote files fetched via HTTP.
>
> With GitLab 11.7, users can include their snippets of configuration also from
> other projects and from the predefined templates.
> GitLab will include snippets for specific jobs, like `sast` or
> `dependency_scanning`, so users can reference them instead of copying and pasting
> the current definition. The jobs will automatically be updated to the latest
> version when GitLab is updated, so there is no need for manual changes.
[Skip CI builds during git push](https://docs.gitlab.com/ee/ci/pipelines/#skip-a-pipeline)
> For commits where users don't want to run the CI/CD pipeline, they were able to add a note to the commit message with `[ci skip]`
> or `[skip ci]`. However, many users don't want to or can't change their commit messages to contain additional information.
>
> As of GitLab 11.7, users can use [Git push options](https://git-scm.com/docs/git-push#git-push--oltoptiongt) in Git 2.10 or newer
> when pushing to GitLab to prevent the pipeline run for their push. Using `git push -o ci.skip` will now achieve the same goal
> without any changes to the commit message.
>
> Thank you [Jonathon Reinhart](https://gitlab.com/JonathonReinhart) for the
> contribution!
[Support for NGINX Ingress 0.16.0+ metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html)
> With the release of [NGINX Ingress 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160),
> Prometheus metrics are now [built in natively](https://github.com/kubernetes/ingress-nginx/pull/2608) rather than relying
> on an external exporter.
>
> GitLab 11.7 now includes [support for the metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html)
> exported by NGINX Ingress 0.16.0+, and will automatically
> detect and display the throughput, latency, and error rate of deployments.