GitLab.org/GitLab: Release v11.10.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 11.10
Released: 2020-04-03
License: MIT
Release Assets:
[Purchase add-on CI Runner minutes](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#extra-shared-runners-pipeline-minutes-quota) (SaaS only)
> Users on GitLab.com's paid plans (Gold, Silver, Bronze) can now purchase
> additional CI Runner minutes. Previously, users were limited by the minutes
> quota included in their plan. This improvement enables users to proactively
> purchase minutes in addition to their free minutes, which reduces
> the potential for any interruptions in service due to stopped pipelines.
>
> The current price is $8 for 1,000 minutes and there is no cap to how
> many add-on minutes you can buy. Your add-on minutes will only begin to be
> used once your monthly quota has been used and whatever add-on minutes are
> left at the end of the month will roll over.
> In a [future release](https://gitlab.com/gitlab-org/gitlab-ee/issues/9919),
> we aim to extend this to Free plans as well.
[Automatically manage group members on GitLab.com using SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html) (SaaS only)
> Until now, managing group membership on GitLab.com was a manual effort.
> You're now able to use SAML SSO and manage group membership with SCIM,
> allowing your organization to create, remove, and update users on GitLab.com.
>
> This is especially useful for enterprises who typically manage large
> numbers of users with centralized identity providers. Now, you're able
> to use a provider like Azure Active Directory as the single source of truth –
> and feel confident that your users will be provisioned and de-provisioned
> automatically based on your identity provider, not by hand.
[Sign in to GitLab.com with your own SAML provider](https://docs.gitlab.com/ee/user/group/saml_sso) (SaaS only)
> Previously, SAML-based SSO for groups required that a user sign in with both their GitLab
> user credentials and their identity provider. Now, a user will be able to use SSO to
> immediately sign in with a GitLab user linked to the configured group.
>
> This removes the need to sign in twice, making SAML SSO more convenient and useful for
> enterprises using it on GitLab.com.
[Child Epics roadmap](https://docs.gitlab.com/ee/user/group/epics/#roadmaps-in-epics)
> In a previous release, we added Child Epics – the ability to have epics
> of epics – to help teams manage work breakdown structures. Child epics are
> shown in the epic page of the parent epic.
>
> With this release, you can now see a roadmap view of the child epics in
> the parent epic page itself. This helps teams see the timeline view of
> those child epics, allowing you to manage time dependencies.
[SAST for Elixir](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)
> We are continuing to add support for more languages and depth in our security scans.
> With this release, we enable security scanning for projects created using
> [Elixir](https://elixir-lang.org/), now broadened to projects created using the
> [Phoenix framework](https://phoenixframework.org/).
[Enrich Container Scanning report with more metadata](https://docs.gitlab.com/ee/user/application_security/container_scanning/)
> This release enriches the Container Scanning report with more metadata,
> adding **impacted component** (a Clair feature) to the
> existing metadata: priority, identifier (with a link on mitre.org), and
> affected layer (ex: "debian:8").
[Show DAST results in the Group Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)
> We have added Dynamic Application Security Testing (DAST) results in the
> Group Security Dashboard to accompany results already present for SAST,
> Container Scanning, and Dependency Scanning.
[Multi-module Maven projects support for Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
> This release enables multi-module Maven projects for GitLab Dependency Scanning.
> Previously, if a sub-module had a dependency with another sub-module sibling,
> it could not resolve the download from the Maven Central repository. Now a multi-module
> Maven project is created with two modules and a dependency between the two modules.
> The sibling dependency is now available in the local Maven repo, permitting the build to continue.
[Monitor resources requested by your cluster](https://docs.gitlab.com/ee/user/project/clusters/#monitoring-your-kubernetes-cluster-ultimate)
> GitLab can assist you by monitoring the Kubernetes cluster you
> use for your staging and production applications. Starting in
> this release, you can monitor the requested CPU and Memory
> resources by your cluster helping you spot potential application
> impacts before they happen.
[Pipelines for Merged Results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipelines-for-merged-results-premium)
> When working in a feature (source) branch, it's normal to have it diverge over time from
> the target branch if you aren't rebasing frequently. This can result in a situation where both the
> source and target branch’s pipelines are green and there are no
> merge conflicts, but the combined output will result in a failed pipeline due to
> an incompatibility between the changes.
>
> By having your merge request pipeline automatically create a new ref that contains
> the combined merge result of the source and target branch, then running the pipeline
> against that ref, we can better ensure that the combined result will be valid.
>
> Please note that if you are using merge request pipelines (in any capacity) and you
> use private GitLab runners that are version 11.8 or older, you will need to upgrade
> them to avoid running into the issue described in [gitlab-ee#11122](https://gitlab.com/gitlab-org/gitlab-ee/issues/11122).
> Users of GitLab's shared Runner fleet are not impacted.
[Simplified and improved license page](https://docs.gitlab.com/ee/administration/license.html) (self-managed only)
> To improve the user experience and make handling license keys
> easier, we've redesigned the license page in the admin panel and emphasized the most important elements of the page.
[Scoped Labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium)
> Scoped Labels enable teams to apply mutually exclusive labels (that share the same scope) on an issue, merge request, or epic, solving the use cases
> of custom fields and custom workflow states. They are configured simply using a special double colon syntax in the label title.
>
> Suppose you wanted a custom field in issues to track the platform operating system that your features target. And each issue should only target one
> platform. You would create labels `platform::iOS`, `platform::Android`, `platform::Linux`, and others, as necessary. Applying any one of these labels
> on a given issue would automatically remove any other existing label that starts with `platform::`, as desired.
>
> Suppose you have the labels `workflow::development`, `workflow::review`, and `workflow::deployed`, representing workflow states of your particular
> team. If an issue already has the label `workflow::development` applied, and a developer wanted to advance the issue to `workflow::review`, they would
> simply apply that label, and the `workflow::development` label would automatically be removed, as desired. This behavior already exists when you move
> issues across label lists in an issue board representing your team's workflow. But now team members who may not be working in an issue board directly,
> would still nonetheless be able to advance workflow states consistently in issues themselves.
[Fix returned
> We fixed a bug in the blob search API with Elasticsearch that was incorrectly
> returning 0 for `project_id`. You will need to [reindex Elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html#adding-gitlabs-data-to-the-elasticsearch-index)
> to get the correct `project_id` values after installing this version of
> GitLab.
project_id in blob search API with Elasticsearch](https://docs.gitlab.com/ee/api/search.html#scope-blobs) (self-managed only)[Pipelines on the Operations Dashboard](https://docs.gitlab.com/ee/user/operations_dashboard/)
> The Operations Dashboard in GitLab is a powerful feature allowing users
> to have an overview of project information throughout the entire GitLab
> instance. You add individual projects, one by one, so it's flexible to
> whichever specific projects are of interest.
>
> With this release, we added pipeline status information to the Operations
> Dashboard. This helps teams view the pipeline health of all the projects
> that they care about, together in a single interface.
[Add metrics report type to merge requests](https://docs.gitlab.com/ee/ci/metrics_reports.html)
> GitLab already provides several report types to be included directly into the merge request – from [Code Quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html)
> and [Unit Test reports](https://docs.gitlab.com/ee/ci/unit_test_reports.html) from the Verify stage to
> [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) and [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) from the Secure stage.
>
> While those specific report types are very valuable, there is also value in providing a primitive that can be used across many different types of use cases.
> In GitLab 11.10 we are shipping metrics reporting directly in the merge request that expects a simple key/value pair of metrics.
> This will allow users to track any changes, including custom metrics, over time and how they change with a given merge request.
> Use cases such as memory usage, specialized load testing, and other code health statuses can be converted to simple metrics
> that will then be exposed directly in the MR alongside the other built-in reports.
[Multiple queries per chart](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics-premium)
> GitLab allows you to create charts to visualize the metrics you
> are collecting. Often, such as when you want to see the maximum
> and average value of a metric, it's crucial to be able to
> visualize multiple values on the same chart. Starting with this
> release, you can now do so.
[Composable Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#using-components-of-auto-devops)
> Auto DevOps enables teams to adopt modern DevOps practices with little to no effort. Starting
> in GitLab 11.10 each job of Auto DevOps is being made available as an
> [independent template](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/gitlab/ci/templates).
> Using the [`includes` feature](https://docs.gitlab.com/ee/ci/yaml/#include) of GitLab CI,
> users can include only certain stages of Auto DevOps while continuing to use
> their own custom `gitlab-ci.yml`. This will enable teams to include just the desired jobs while
> taking advantage of any updates made upstream.
[Enable/disable Auto DevOps at the Group level](https://docs.gitlab.com/ee/topics/autodevops/#enablingdisabling-auto-devops-at-the-group-level)
> Enabling Auto DevOps for your GitLab.com project provides an easy
> way to get started with modern DevOps workflows, from build all the way to deploy.
>
> Starting with GitLab 11.10 we've added the ability to enable/disable Auto DevOps
> for all the projects that are part of any given group.
[Update Kubernetes deployments label selector](https://docs.gitlab.com/ee/user/project/deploy_boards.html#enabling-deploy-boards)
> Deploy boards provide an easy way to gain insight into your Kubernetes deployments.
>
> As part of this release, we're updating the way labels are matched to deployments; deploy boards
> will now match by `app.example.com/app` and `app.example.com/env` or `app`. This will allow us to prevent
> conflicts when doing filtering and risk incorrect deploys associated to the project.
>
> Additionally, starting in GitLab 12.0 we will [remove 'app' label matching from Kubernetes deployment selector](https://gitlab.com/gitlab-org/gitlab-ee/issues/11209)
> and will instead match only on `app.example.com/app` and `app.example.com/env`.
[Just-in-time Kubernetes resource creation](https://docs.gitlab.com/ee/user/project/clusters)
> GitLab's Kubernetes integration takes advantage of RBAC security by creating a service account and a dedicated
> namespace for each GitLab project. Starting with this release, to maximize the efficiency with which
> these resources are created, they will be created only when they are needed for deployment.
>
> When a Kubernetes deployment takes place, GitLab CI will create the resources prior to deployment.
[Group Runners for group-level clusters](https://docs.gitlab.com/ee/user/group/clusters/#installing-applications)
> Group-level clusters now support the installation of GitLab Runner. Group-level Kubernetes runners
> will appear for child projects as group runners tagged with the labels `cluster` and `kubernetes`.
[Show function invocation count for Knative functions](https://docs.gitlab.com/ee/user/project/clusters/serverless/#function-details)
> Functions deployed with [GitLab Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
> will now include the number of invocations received for the particular function. Showing the number of invocations
> requires Prometheus to be installed on the cluster where Knative is installed.
[Allow Developers to create projects in groups in Core](https://docs.gitlab.com/ee/user/group/#default-project-creation-level)
> We added a configurable option to allow the Developer role to create projects
> in groups [back in 10.5](https://gitlab.com/gitlab-org/gitlab-ee/issues/2534),
> and we're adding this option to Core. Creating projects is a key capability
> for productivity in GitLab, and moving this option to Core helps reduce barriers
> when members of an instance want to work on something new.
[External Authorization in Core](https://docs.gitlab.com/ee/administration/settings/external_authorization.html)
> Secure environments may require checking with an additional external authorization
> resource to permit project access. We added support for this additional layer of
> access control [in 10.6](https://gitlab.com/gitlab-org/gitlab-ee/issues/4216),
> and we've heard requests from the community to move this functionality to Core.
> We're happy to do this for External Authorization
> and bring this additional level of security to Core instances, since it's a feature
> cared about by individual contributors.
[GitLab Runner 11.10](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 11.10 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 option to specify clone path](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267).
> * [Improve support for `git clean`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1281).
> * [Allow users to disable debug tracing](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1286).
> * [Use delayed variable expansion for error check in Windows Cmd](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1260).
> * [Fix color output on Windows](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1208).
>
> List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.10.0/CHANGELOG.md).
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> The following improvements have been made to Omnibus in GitLab 11.10:
>
> - GitLab 11.10 includes [Mattermost 5.9.0](https://mattermost.com/blog/mattermost-5-9/),
> an [open source Slack-alternative](https://mattermost.com/) whose newest release includes
> a new Integrations Directory, a simple way to migrate data from Hipchat, and much more.
> This version also includes [security updates](http://about.mattermost.com/security-updates/)
> and upgrading is recommended.
> - GitLab dashboards are now [pre-loaded in the bundled Grafana](https://docs.gitlab.com/omnibus/settings/grafana.html#dashboards),
> making it even easier to begin monitoring your instance of GitLab.
> - We have added support to clean up old container images from the Docker registry.
> - We have updated ca-certs to 2019-01-23.
[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.10)
> We continue to improve the performance of GitLab with every release
> for GitLab instances of every size. Some of the improvements in GitLab
> 11.10 are:
>
> - [Users autocomplete is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/43065#note_160130314).
> - [Optimize SQL queries used for listing project issues when searching](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26908#note_160151161).
> - [Elasticsearch search results no longer hit Gitaly](https://gitlab.com/gitlab-org/gitlab-ee/issues/9927).
> - [GraphQL queries have a complexity limit applied](https://gitlab.com/gitlab-org/gitlab-ce/issues/58405).
> - [Disable method instrumentation for diffs to improve performance of merge requests when Prometheus is enabled](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27235).
> - [Improve performance of GitHub Pull Request import](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27121).
> - [Cache commit lookups based on refname](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26248).
> - [Improves performance of merge requests diffs by memoizing diff file blobs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26604).
[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only)
> The following improvement has been made to GitLab charts:
>
> - [Support for Elasticsearch](https://gitlab.com/charts/gitlab/issues/976) has been added.
[Suggest changes to multiple lines](https://docs.gitlab.com/ee/user/discussions/#multi-line-suggestions)
> Collaborating on merge requests often involves spotting problems and
> suggesting a solution. In GitLab 11.6, we introduced support for
> [suggesting a change](/releases/2018/12/22/gitlab-11-6-released/#suggested-changes)
> to a single line.
>
> With 11.10, changes can now be suggested to multiple lines
> when leaving a comment on a merge request diff, and accepted with a
> single click, by any user with write permissions to the source branch.
> This new feature avoids the copy/paste workflow of old.
[Merge request popovers](https://docs.gitlab.com/ee/user/project/merge_requests/)
> In this release, we introduce enriched popovers when hovering over a
> merge request link. While we previously only displayed the title of the
> merge request, you can now view the merge request status, CI pipeline
> status, title, and short URL.
>
> In future releases, we plan to add additional important information like
> [assignees and milestones](https://gitlab.com/gitlab-org/gitlab-ce/issues/59194)
> and bring popovers to
> [issues](https://gitlab.com/gitlab-org/gitlab-ce/issues/54915) too.
[Filter merge requests by target branch](https://docs.gitlab.com/ee/user/search/index.html#issues-and-merge-requests-per-project)
> Git workflows for releasing or deploying software often involve
> multiple long-running branches, either for backporting fixes to older
> versions (e.g. `stable-11-9`) or moving through a QA process to
> product (e.g. `integration`), but finding the merge requests that
> target these branches can be difficult among many open merge requests.
>
> The merge request list for projects and groups can now be filtered by
> the target branch of the merge request, making it simpler to find the
> merge request you are looking for.
>
> Thank you, [Hiroyuki Sato](https://gitlab.com/hiroponz), for the
> contribution!
[Push and merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/#git-push-options)
> Trunk-based development claims that long-running branches should be
> avoided in favor of small, short-lived, single-owner branches. For
> the smallest changes it is not uncommon to push directly to the target
> branch, but this runs the risk of breaking the build.
>
> In this release, GitLab supports new Git push options to open a merge
> request automatically, set the target branch, and enable merge when the
> pipeline succeeds via the command line, at the moment that you push to
> your branch.
[Sort Wiki pages by created date](https://docs.gitlab.com/ee/user/project/wiki/index.html)
> A project's Wiki allows teams to share documentation and other important
> information conveniently, side by side with source code and issues. In
> this release, the list of pages in a Wiki can be sorted by created date
> and title, allowing users to locate recently created content quickly.
[Allow users to change the path for cloning in CI](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#custom-build-directories)
> By default, the GitLab Runner clones the project to a unique subpath of the `$CI_BUILDS_DIR`.
> However, for some projects, such as Golang projects, there may be a requirement to have the
> code cloned to a specific directory to be built.
>
> In GitLab 11.10, we've introduced a variable called `GIT_CLONE_PATH` that allows users
> to specify the specific path that the GitLab Runner will clone to before starting the job.
[Simple masking of protected variables in logs](https://docs.gitlab.com/ee/ci/variables/#masked-variables)
> GitLab provides several ways to [protect](https://docs.gitlab.com/ee/ci/variables/#protected-environment-variables) and
> [limit the scope](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables)
> of variables in GitLab CI/CD. However, there are still ways that variables
> can leak into build logs, either intentionally or unintentionally.
>
> GitLab takes risk management and audit seriously and continues to add features to help with compliance efforts.
> In GitLab 11.10, we've added the ability to mask certain types of variables if they are found in the job trace logs,
> adding a level of protection against accidentally leaking the content of those variables into the logs.
> Also, GitLab will now [automatically mask](https://docs.gitlab.com/ee/ci/variables/#masked-variables) many of the built-in token variables.
[Add control for
> By default, GitLab Runner runs a `git clean` as part of the process of checking out your code
> while running a job in GitLab CI/CD. In GitLab 11.10, we're adding the ability for users to control
> the flags passed to the `git clean` command. This will help teams who have dedicated runners or are building
> projects from large mono repositories to manage the checkout process prior to executing their scripts.
> The new variable `GIT_CLEAN_FLAGS` defaults to `-ffdx` and accepts all the possible options of
> the [`git clean`](https://git-scm.com/docs/git-clean) command.
git clean flags for GitLab CI/CD jobs](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#git-clean-flags)[More thorough Container Registry cleanup](https://docs.gitlab.com/omnibus/maintenance/#removing-unused-layers-not-referenced-by-manifests)
> In normal use of the Container Registry with CI pipelines, typically you will end up pushing many iterative
> revisions to the same tag. Due to the way Docker Distribution is implemented, the default behavior is to
> preserve all revisions in the system – this ends up consuming a lot of space under this usage pattern.
> By using the `-m` parameter with `registry-garbage-collect`, administrators now have an easy way to wipe
> out these historical revisions and free up valuable storage space.
[Improved integration with external monitoring dashboards](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#managed-prometheus-on-kubernetes)
> GitLab can access multiple Prometheus servers (at the environment,
> project and [soon group levels](https://gitlab.com/gitlab-org/gitlab-ce/issues/51963)) but the complexity of multiple
> endpoints can be difficult or unsupported by common dashboarding
> tools. In this release teams can now interact with a single
> Prometheus API interface, making integration with services like
> Grafana much simpler.
[See Load Balancer metrics in your Grafana dashboard](https://docs.gitlab.com/omnibus/settings/grafana.html#dashboards) (self-managed only)
> Ensuring your GitLab instance stays healthy is critical. We've
> previously given you default dashboards to review in our bundled-in
> Grafana instance. Starting with this release, we now include
> additional dashboards to monitor your NGINX load balancers.