GitLab.org/GitLab: Release v11.8.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 11.8
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)
[Scroll roadmap forward into the future and backward into the past](https://docs.gitlab.com/ee/user/group/roadmap/)
> When you first load the roadmap view, GitLab preselects a time period for you,
> with options to select weekly, monthly, or quarterly intervals. But the
> view was fixed, and epics outside of what was displayed were hidden.
>
>
> With this release, you can now scroll forward into the future and backward
> into the past. Epics that fall in these expanded times will automatically
> appear in the view, without requiring you to refresh the page in any way,
> allowing you a seamless experience to see even more epics in as long of a
> timeline you need.
[Child Epics in Epics API](https://docs.gitlab.com/ee/api/epic_links.html)
> In our previous release, we launched [child epics](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#multi-level-child-epics),
> the ability to attach epics to epics. With this release, you can now manage
> these epic relationships via the API as well. So you can now manage customized
> workflows in your teams, especially through automation.
[SAST support for JavaScript](https://docs.gitlab.com/ee/user/application_security/sast/)
> Static Application Security Testing (SAST) allows you to spot vulnerabilities
> in your source code every time you commit a new change to the repository.
> With this information available in the merge request, you can shift security left
> and address problems even before they are merged into the stable branch.
>
> With 11.8, we add JavaScript to the list of languages supported by SAST.
> You don’t need to change anything in your pipelines. JavaScript projects are
> automatically detected and analyzed for security vulnerabilities. It is also
> part of [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast).
[Confidential issues for security vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports-ultimate)
> Users can create a new issue to address and remediate security vulnerabilities
> from the security reports in a merge request, in the pipeline view, and in
> the Security Dashboard. This information contains sensitive data that
> may disclose confidential details that should not be disclosed before a fix
> is available and released.
>
> Starting with GitLab 11.8, issues created from a vulnerability are marked as
> [confidential](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html)
> by default, and users can turn the flag off when the information can be disclosed.
[Receive alerts from manually configured Prometheus instances](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#external-prometheus-instances)
> In GitLab 11.3 support for [setting alerts was introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/#alerts-for-library-metrics), however it was limited to Prometheus instances
> which were deployed through the GitLab [Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/#installing-applications).
>
> With GitLab 11.8, manually configured Prometheus servers can now also notify GitLab of alerts, by simply adding GitLab as a webhook receiver in alertmanager.
> After receiving an alert, GitLab will email Maintainers and Owners of the project.
[Authenticate credentials from a smart card with LDAP](https://docs.gitlab.com/ee/administration/auth/smartcard.html)
> Organizations using smart cards as authentication tokens frequently use LDAP
> for centralized identity management. In 11.8, we're iterating on the smart card
> authentication [added in 11.6](https://gitlab.com/gitlab-org/gitlab-ee/issues/726) by
> allowing credentials on a smart card to be authorized against a configured LDAP server.
>
> GitLab's approach follows [RFC4523](https://tools.ietf.org/html/rfc4523) schema standards
> using the `certificateExactMatch` rule.
[Feature Flags for Environments](https://docs.gitlab.com/ee/operations/feature_flags.html#define-environment-specs)
> It is now possible to individually turn feature flags on or off on a per-environment
> basis. The behavior of your feature flags is controlled by creating a set of rules based
> on matching the environment name. There is always a default wildcard rule (`*`), but you are also able to add
> more rules by adding more environment specs (for example, `review/*`).
>
> In 11.8.0 this feature will require enabling the feature flag, by executing
> `Feature.enable(:feature_flags_environment_scope)` in the rails console.
[Gitaly support for Elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html) (self-managed only)
> Previously, you had to use NFS to talk to Git in the filesystem if you
> were using Elasticsearch. With this release, you can use Gitaly instead
> of NFS, improving Git access performance.
[Merge Request Approval Rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#multiple-approval-rules)
> Code review is an essential practice of every successful project, but
> who should review the changes is not always clear. It is frequently
> desirable to have a variety of reviewers from different teams like
> Engineering, UX, and Product.
>
> Approval Rules, new in GitLab 11.8, allow you to better communicate who
> should participate in code reviews by specifying the eligible
> approvers and the minimum number of approvals for each. Approval rules
> are shown in the merge request widget so the next reviewer can quickly
> be assigned.
>
> In GitLab 11.3 we introduced
> [Code Owners](/releases/2018/09/22/gitlab-11-3-released/#code-owners)
> to indicate which team members are responsible for which code in your
> project. Code owners are integrated into approval rules so that finding
> the right people to review your change is always easy.
>
> Approval Rules are disabled by default in 11.8 and must be enabled by
> an instance administrator by executing
> `Feature.enable(:approval_rules)` in the rails console.
>
> Approval Rules have temporarily been disabled on GitLab.com. We expect
> to be re-enabled after deploying GitLab 11.8.1. Follow
> [this issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/9913)
> for updates.
> {: .alert .alert-info}
[Approval counts in the merge request list](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
> Merge requests that are approved and ready to merge can now be spotted
> easily from the merge request list. The number of approvals required and
> number of approvals received is now shown in the merge request
> list.
>
> Thank you [Andy Steele](https://gitlab.com/spacemeld) for the contribution!
[Improved cross-project pipeline triggers](https://docs.gitlab.com/ee/ci/yaml/#trigger)
> Starting with [GitLab 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs), you've been able to create [multi-project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html)
> by triggering a downstream pipeline via a GitLab API call in your job. In 11.8, we've added first-class support for triggering
> these downstream pipelines with the `trigger:` keyword, which can be added to a bridge job to automatically trigger a downstream pipeline when the current pipeline succeeds.
[Create Pages sites in one click using bundled templates](https://docs.gitlab.com/ee/user/project/pages/#getting-started)
> We are now bundling our most popular Pages templates directly in
> GitLab, opening up the possibility of creating your sites directly
> from the new project creation screen instead of having to fork
> a sample repository as before.
>
> Check out our [blog post about using GitLab Pages templates](/blog/2019/02/20/start-using-pages-quickly/) for more.
[Pages support for subgroups](https://docs.gitlab.com/ee/administration/pages/)
> Pages have been updated to work with subgroups in GitLab, giving
> you the ability to create Pages sites there as well. Sites
> set up in this way will have a URL in the format of
> `toplevel-group.gitlab.io/subgroup/project`. This will give your
> projects, even when part of subgroups, access to the ability to
> create documentation or other sites needed as part of releasing
> your software.
[Auto DevOps support for environment-specific custom domain](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables)
> Auto DevOps allows you to quickly get started by adding a "base domain" for your projects.
> When your application is ready for production deployment, you may then want to use a
> custom, fully qualified domain name.
>
> You can now use the environment variable `ADDITIONAL_HOSTS` to specify one or more custom
> domains for your application. Furthermore, you can scope it to a specific environment
> by prepending the environment name to the variable, ie. `[Show function scale for Knative functions](https://docs.gitlab.com/ee/user/project/clusters/serverless/#deploying-functions)
> Deploying functions using GitLab Serverless comes with all the benefits of Knative, such as
> scaling your serverless deployments up and down to zero.
>
> You can now see the scale of your serverless deployments for each application or function
> deployed to your Knative instance. Scale is illustrated by the number of Kubernetes
> pods currently in use.
[Specify the first day of the week](https://docs.gitlab.com/ee/user/profile/preferences.html)
> Before, calendars in GitLab assumed that weeks began on Sunday. Users
> can now elect in their profile preferences to have their first day of the
> week begin on Monday, which is reflected throughout the application in
> date pickers and contribution graphs.
>
> Thank you [Fabian Schneider](https://gitlab.com/fabsrc) for the contribution!
[Upgrade Kubernetes Runner application via Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/#installing-applications)
> Keeping your Kubernetes-deployed apps running on the latest version ensures you have
> the newest features as well as up-to-date security.
>
> GitLab 11.8 allows you to upgrade the GitLab runner running in Kubernetes with a single click.
> Future releases will include similar functionality for the rest of the applications.
[User activity and creation dates shown in admin panel](https://docs.gitlab.com/ee/api/users.html#for-admins)
> Understanding the activity level of users in GitLab should be an easy task
> for instance administrators. To help, we've added user creation date and
> the date of a user's last activity to the Users area of the admin panel
> at `/admin/users`.
>
> You can read more about the types of actions GitLab considers activity [here](https://docs.gitlab.com/ee/user/instance_statistics/user_cohorts.html).
[Record of a user's last activity in GitLab now includes browsing](https://docs.gitlab.com/ee/user/instance_statistics/user_cohorts.html)
> GitLab includes a user attribute, `last_activity_on`, to help admins understand
> when a user's last activity was taken. This is very helpful for finding active and
> inactive users.
>
> To ensure we're capturing read-only activity, we've expanded last_activity_on to
> update on visits to pages related to dashboards, projects, issues, and merge requests.
[Project tags are now project topics](https://docs.gitlab.com/ee/user/project/settings/#general-project-settings)
> Project tags are a useful way to organize related projects, but the term "tag" collided with
> Git tags. To resolve this, we've renamed project tags to project topics and [improved their presentation](https://gitlab.com/gitlab-org/gitlab-ce/issues/54544)
> on the project overview page.
>
> We're excited to make topics more useful for project discoverability, and are
> [adding topic filtering](https://gitlab.com/gitlab-org/gitlab-ce/issues/54372) to the project dashboard
> in 11.9.
[Search repository tags in a project via the API](https://docs.gitlab.com/ee/api/tags.html)
> You can now search for repository tags in a project via the
> [Tags API](https://docs.gitlab.com/ee/api/tags.html). This makes finding
> a specific tag in a project more straightforward; if you're looking
> for related projects that match a specific version tag, you're now able
> to find matching projects with ease.
>
> Thank you [Robert Schilling](https://gitlab.com/razer6) for the contribution!
[Improved project lists with more information density](https://docs.gitlab.com/ee/user/project/)
> We've responded to user feedback on our [first project list redesign](https://gitlab.com/gitlab-org/gitlab-ce/issues/51944)
> by improving the information density on this page with an additional
> column and less whitespace.
[Improved group overview with reduced white space](https://docs.gitlab.com/ee/user/group)
> In 11.8, we've made the group overview more information dense with a redesign. We've
> reduced the amount of whitespace on this page and aligned the user experience with the
> [project overview redesign](https://gitlab.com/gitlab-org/gitlab-ce/issues/44704).
>
> This is the first iteration of a [larger set of improvements](https://gitlab.com/gitlab-org/gitlab-ce/issues/50836)
> to the group overview page, and we're excited to continue iterating on this page.
[Move Auto DevOps domain from CI/CD settings to cluster settings](https://docs.gitlab.com/ee/topics/autodevops/#auto-devops-base-domain)
> Specifying a base domain for Auto DevOps allows you to take advantage of powerful features such as
> Auto-Review Apps and Auto-Deploy. We've now made it even easier to specify the base domain by
> moving it directly to cluster settings. This will make it simple to define the base domain when
> the cluster is created, and also to define different domains for different clusters.
[.html extensions are now automatically resolved for Pages sites](https://docs.gitlab.com/ee/user/project/pages/)
> A file in your Pages site called `/sub-page.html` can now also be
> accessed as `/sub-page`, giving you more options over how your
> site appears to your users.
[Predefined Pages variables in CI](https://docs.gitlab.com/ee/user/project/pages/)
> `CI_PAGES` and `CI_PAGES_URL` have been added as CI variables for
> Pages pipelines, giving you visibility into the Pages domain name
> and URL. This allows for more flexibility when working with
> Pages sites hosted in multiple locations.
[Force re-deploy when Auto DevOps application secrets are updated](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables)
> When you configure an app secret for Auto DevOps using the `K8S_SECRET_` variable syntax,
> a matching Kubernetes secret will be created for your application.
>
> When these app secrets are updated, Auto DevOps will redeploy your application with the updated
> secrets.
>
> Thank you [Aaron Walker](https://gitlab.com/walkafwalka) for the contribution!
[Display cluster environment in serverless function list view](https://docs.gitlab.com/ee/user/project/clusters/serverless/#deploying-functions)
> The Serverless page has been improved and will now group functions deployed to Knative
> based on the cluster environment they are deployed to.
>
> In addition, function description is now displayed along with shortcut button to copy
> the function endpoint and another open the endpoint in a new tab.
[Ensure Cert-Manager works with Auto DevOps URLs](https://docs.gitlab.com/ee/topics/autodevops/#auto-devops-base-domain)
> Cert-Manager provides an easy way to add HTTPS support for your
> Auto DevOps applications. This release adds support for URLs longer than
> the default 64 characters supported by Let's Encrypt, providing more
> flexibility for your applications.
[GitLab Runner 11.8](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 11.8 today! [GitLab Runner](https://docs.gitlab.com/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 fix for race condition in windows cache extraction](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/863)
> * [Prevent Executors from modifying Runner configuration](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1134)
> * [Add support for fedora/29 packages](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1082)
> * [Update Docker client SDK](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1148)
>
> List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.8.0/CHANGELOG.md).
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab's [docker-distribution-pruner](https://gitlab.com/gitlab-org/docker-distribution-pruner) is now bundled with Omnibus, allowing administrators a method to clean up registry storage.
> - GitLab 11.8 includes [Mattermost 5.7.1](https://mattermost.com/blog/mattermost-5-7-the-most-secure-way-to-adopt-chatops-performance-improvements-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes several user experience improvements. This version also includes [security updates](http://about.mattermost.com/security-updates/) and upgrading is recommended.
> - `node_exporter` no longer runs by default in the Omnibus docker image, as it requires access to the host.
> - Additional alerts have been added, notifying administrators about: high unicorn utilization, sidekiq job queues, postgres deadlocks, high error rates, and more.
> - `nginx` has been updated to 1.12.2, `registry` to 2.7.1, and `gitlab-elasticsearch-indexer` to 1.0.0.
> - `prometheus` has been updated to 2.6.1, `node_exporter` to 0.17.0, and `redis_exporter` to 0.26.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.8)
> We continue to improve the performance of GitLab with every release,
> for GitLab instances of every size.
>
> In GitLab 11.8, we have significantly improved the performance of
> checking task lists in issues, merge requests, and epics by [not
> re-rendering the entire description after a task is checked or
> unchecked](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23938)
[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only)
> - GCS is now a [supported bucket type for backups](https://docs.gitlab.com/charts/advanced/external-object-storage/index.html#backups-storage-example)
> - Postgres databases with [mutual TLS authentication](https://docs.gitlab.com/charts/advanced/external-db/index.html#configuring-gitlab-to-use-an-external-database) can now be utilized
> - `ruby` has been updated to 2.5.3
[Redesigned related merge requests, consistent with related issues](https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html#from-merge-requests)
> We've restyled the related merge requests section in an issue, to bring
> visual consistency to related issues and improve aesthetic appearance.
>
> We're even [adding more metadata](https://gitlab.com/gitlab-org/gitlab-ce/issues/51862)
> to each row in the design in a future release, to help users see relevant
> merge request information even more quickly and in context.
[Manage group labels via the API](https://docs.gitlab.com/ee/api/group_labels.html)
> You can now manage group labels via the API, similar to project labels,
> helping further support customized planning and execution workflows
> on your teams.
>
> Thank you [Robert Schilling](https://gitlab.com/razer6) for the contribution!
[Improved squash commit messages](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html)
> Creating Git history that is readable and useful to people in the
> future can be at odds with pushing small commits to fix a unit test
> or resolve feedback. Commit squashing combines all these commits into
> a single tidy change, but at the same time wipes out your thoughtful
> commit messages.
>
> GitLab now defaults the squash commit message to the first multi-line
> commit message in the feature branch, and allows you to override the
> commit message so that you can update it to reflect any important
> changes.
[Gitaly support for TLS](https://docs.gitlab.com/ee/administration/gitaly/#tls-support)
> Gitaly now supports TLS, which means all communication between GitLab
> and Gitaly will be encrypted when TLS is enabled. Previously,
> communication between GitLab and Gitaly was not encrypted, but relied
> on the security of the network.
[Jump to file in merge request diff](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-diff-file-navigation)
> Reviewing large merge requests can be difficult, particularly jumping
> from one file to another. The new fuzzy file finder makes moving from
> one file to another painless, so that you can quickly navigate the diff
> using your keyboard.
[Add tolerations to Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html#the-keywords)
> Kubernetes provides an exciting opportunity to disconnect the underlining hardware from where our workloads run. However, some tasks require specialized hardware – including jobs that may require more resources than others.
>
> Kubernetes supports this by introducing [taint and toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to nodes in order to include these considerations when scheduling pods. We've added native support for taints and tolerations in the Kubernetes executor in GitLab Runner to support these types of workflows.
[Clean up unused tags from the Container Registry using the API](https://docs.gitlab.com/ee/api/container_registry.html#delete-a-repository-tag)
> Many organizations build containers on every commit, to facilitate validation of code changes, as well as final deployment.
> This can lead to a large number of container tags that are used for a short period of time, and are no longer necessary.
>
> GitLab 11.8 now allows end users to clean up their container registries using our API, by deleting tags singly or in bulk using a regex.
[Error tracking with Sentry](https://docs.gitlab.com/ee/operations/error_tracking.html)
> Keeping an eye on errors generated by your application helps maintain a good user experience
> by detecting problems before users report them and speeding up resolution when they occur.
>
> GitLab 11.8 makes it more convenient and efficient to monitor errors by integrating with
> popular open source error tracker Sentry, and displaying the most recent errors right within your GitLab project.
>
> Sentry has recently [improved their GitLab integration](/blog/2019/01/25/sentry-integration-blog-post/),
> enabling detection of suspicious commits, release and commit tracking, and more. With the combination of both integrations
> you'll have a simple path to Sentry from GitLab, as well as a clean way to get to GitLab from Sentry, so that
> you can always address errors contextually, staying within your existing workflow.