GitLab.org/GitLab: Release v12.8.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.8
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Compliance Dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/index.html):
> Compliance-minded organizations need visibility. This becomes more difficult as more groups, projects, and users are added to GitLab, which can make it difficult to manage risk and compliance appropriately.
>
> In GitLab 12.8, we've added a group-level dashboard as a first iteration towards bringing compliance insights to group owners. This first iteration focuses on aggregating all of the most recent merge requests (approved and merged) from each project in a group. Group owners can now see all of their merge request activity to be informed and take action if necessary.
Audit Reports[Credential inventory for group-managed accounts](https://docs.gitlab.com/ee/user/group/saml_sso/index.html#credentials-inventory-for-group-managed-accounts-ultimate):
> Managing access to your GitLab.com groups requires visibility into the credentials people are using to take actions within those groups.
>
> In GitLab 12.8, we've extended the credentials inventory from self-managed instances to GitLab.com. Now, owners of group-managed accounts can view the SSH credentials and personal access tokens that exist within their groups. This inventory shows the user, the type of credential, and the expiration date so you can make informed decisions about access and rotation.
Compliance Management[Instance-level Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#instance-security-dashboard):
> An instance-level view of the security vulnerabilities is now available. Use this dashboard to see an overview of possible security issues across all of your groups and projects.
>
> In addition to seeing a list of vulnerabilities in your projects and a trend of vulnerabilities over time, you are now able to see your projects across all of your groups categorized by their Security Report letter grade for quick decision making as to which project needs the most attention.
DAST, SAST, Dependency Scanning, Container Scanning, Vulnerability Management[Support Go Modules in Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> We are excited to add support for [Go Modules](https://github.com/golang/go/wiki/Modules) as a Dependency Scanning [supported language](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers).
>
> Although this scanner is viable, the feature is currently in alpha as the database only contains Go Module vulnerability definitions from 2019 and later. We appreciate any feedback [in this epic](https://gitlab.com/groups/gitlab-org/-/epics/2206) around the age and types of Go support desired in addition to any issues you experience. It will help us continue to move this language support out of alpha.
Dependency Scanning[Rapidly updated vulnerability database](https://docs.gitlab.com/ee/user/application_security/#maintenance-and-update-of-the-vulnerabilities-database):
> We keep updating our vulnerability database with the latest vulnerabilities. This ensures that GitLab's scanners are always scanning for the latest vulnerabilities, protecting you and your applications.
>
> In February 2020, we've added known vulnerabilities to our database on average within 2.2 days of their announcement. You can see the latest status of our vulnerability updates in the [Handbook](/handbook/engineering/development/performance-indicators/#cve-issue-to-update).
Vulnerability Database[Network Policies for Container Network Security](https://docs.gitlab.com/ee/user/clusters/applications.html#install-cilium-using-gitlab-cicd):
> We're pleased to announce initial support for Container Network Security to help prevent lateral security attacks. You can now configure Network Policies in GitLab-managed Kubernetes clusters to limit communication between Kubernetes pods.
>
> Network Policies can control communication between pods and the internet and can prevent unauthorized pods from communicating with other pods in the same Kubernetes cluster. In a multi-application cluster, this feature also enables network segmentation between the different applications.
Container Network Security[Explore aggregated logs](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html#full-text-search):
> In a cloud-native world with short-lived services and logs distributed across multiple pods and services, aggregation of logs for observability becomes critical. GitLab 12.8 introduces log aggregation using the Elastic stack.
>
> After attaching a Kubernetes cluster, you can install the Elastic stack, which contains an Elasticsearch instance with Filebeat, a light-weight log shipper. Once enabled, GitLab automatically collects all application logs and surfaces them on the UI.
>
> With this, you will be able to view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs.
>
> This can be useful if you are triaging an application incident or validating the status of your service and need to explore logs from across your application and conduct a full-text search. It also helps you to understand what is affecting your application's performance and resolve any problems as they arise.
Logging[Navigate from metrics chart to logs](https://docs.gitlab.com/ee/user/clusters/applications.html#elastic-stack):
> When troubleshooting an incident, reviewing both logs and metrics is important. When viewing a metric chart, you can now drill down directly into the log explorer while preserving context and without ever leaving the GitLab console.
Metrics[Collect Release Evidence at Release end date](https://docs.gitlab.com/ee/user/project/releases/#scheduled-evidence-creation):
> When users first create a Release entry, a snapshot of the metadata is taken for Evidence in the event of an audit. As of 12.8, we automatically take an additional snapshot of the Release Evidence at the Release end date. By providing a second snapshot, it becomes possible to compare the start state of a Release with its end state. This gives audit teams better visibility into what changed between these two points in time.
Release Orchestration[Geo moves towards a self-service developer framework](https://docs.gitlab.com/ee/development/geo/framework) (self-managed only):
> Geo helps distributed teams by replicating data to local Geo nodes, and is also used for disaster recovery. Today, some of GitLab's features are [not yet supported by Geo](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#limitations-on-replicationverification). We want all upcoming features to ship with Geo support out of the box. To accomplish this, we are moving towards a developer framework, which will make it easier for developers in the GitLab community to contribute new data types that need to be replicated and verified.
>
> This is valuable, because it standardizes the technical processes used in Geo to extend Geo to other parts of GitLab, and it will give the GitLab developer community a solid technical foundation to contribute future features and improvements to Geo. Effectively, future development work will be faster and more efficient.
>
> In this release, we have merged [a significant first iteration for package files](https://gitlab.com/gitlab-org/gitlab/issues/197319) that establishes the technical foundations of this work. In the next iteration, we will add support for package file replication and verification.
Geo-replication, Disaster Recovery[Disable self-approval at the instance level](https://docs.gitlab.com/ee/administration/merge_requests_approvals.html) (self-managed only):
> We've introduced new instance-level settings to prevent unwanted changes to merge request approval settings by bringing some of the merge request approval settings from the project settings into the Admin Area. This will give administrators better control of their deployments and allow them to maintain separation of duties when deploying code.
>
> By enabling these settings at the instance level, all projects in a self-managed instance are forced to adopt these settings, and only administrators can change them for an individual project. This new enforcement capability ensures only approved deployments make it into production and brings your GitLab projects into a more compliant state.
Compliance Management[Manage access to protected environments from the API](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#use-the-api-to-protect-an-environment):
> Until now, users configuring access levels for protected environments needed to update developer and maintainer permissions through the Settings UI instead of the CLI. This wasn't efficient for users who want to work from the command line and need to maintain the same level of environment access across groups. With this release, maintainers can save time when adding or removing access to protected environments by using the API, rather than having update permissions in the Settings UI.
Release Governance, Release Orchestration[New audit events](https://docs.gitlab.com/ee/administration/audit_events.html#instance-events):
> We're continuing to add audit events to improve the visibility of activity in your self-managed instances and GitLab.com groups. In this release, we've added administrator actions to [create, block, or delete users](https://gitlab.com/gitlab-org/gitlab/issues/251) and [include username changes](https://gitlab.com/gitlab-org/gitlab/issues/7797) in the self-managed instance logs.
>
> These new audit events will help compliance-minded organizations to maintain separation of duties, access management, and nonrepudiation.
Audit Events[Single-level Epics now available in Premium!](https://docs.gitlab.com/ee/user/group/epics/):
> To support our users who are planning larger collections of related work and manage them across multiple milestones, sprints, and iterations for their teams, we are releasing single-level Epics for our Premium customers!
>
> Spin up an Epic, create and add associated issues, set start and due dates, and organize it quickly with our drag-and-drop Epic Tree.
Epics[Blocking issue support](https://docs.gitlab.com/ee/user/project/issues/related_issues.html):
> Clearly defining issue dependencies has just become easier. You can now mark issues as blocking or blocked by other issues. With this new dependency construct, it is now easier than ever to understand issues that may need extra attention (blocked), or to identify issues which will yield high rewards (blocking)! Collaboration efficiency is also increased as inter-team dependencies can now be represented.
Requirements Management[Issue Board Work In Progress Limits](https://docs.gitlab.com/ee/user/project/issue_board.html#work-in-progress-limits-starter):
> The more issues in progress in a given workflow stage, the longer it takes to complete any one given issue. Work In Progress (WIP) limits are commonly used by teams that practice Kanban and is a proven method to improve throughput.
>
> As of 12.8, you can now set WIP limits based on max Issue count per list in an Issue Board. If you exceed your limit, the list background color will change to red.
Boards[Visually differentiate blocked issues on issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#blocked-issues):
> Blocked issues need attention! Being able to differentiate which issues are blocked while looking at your issue board makes it easier than ever to identify what may be slowing down your team. Remove blockers, and enable your team to run more efficiently than ever!
Issue Tracking[Change the name of the Service Desk user](https://docs.gitlab.com/ee/user/project/service_desk.html#using-custom-email-display-name):
> Emails sent from your Service Desk on GitLab.com come from the `GitLab Support Bot` by default. Many times, the originator of the issue does not know that they are emailing GitLab, which makes it confusing.
>
> It's now possible to configure the name for your Service Desk user! This allows you the opportunity to give your users a recognizable name that matches your brand!
Service Desk[Merge Request Approval Rules for Protected Branches](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#scoped-to-protected-branch):
> Code review is an essential practice of every successful project, and Approval Rules can be used to make sure the right people review each change. When practicing continuous delivery or working on higher risk projects, this is especially important. Previously, adding more restrictive approval requirements to protect the default branch would impose the same requirements on every branch. This forced all merge requests to meet the same approval requirements, whether it be merging a bug fix from `master` into a release branch, or between two feature branches.
>
> GitLab 12.8 resolves this problem: Approval Rules for Merge Requests set at the project level can be required selectively based on the target branch of the merge request. This allows restrictive approval rules to apply exactly when needed, and even different approval rules to apply to different branches like for stable release branches.
Source Code Management[Drag-and-drop Design badges](https://docs.gitlab.com/ee/user/project/issues/design_management.html#adding-annotations-to-designs):
> When viewing a design inside the **Design** tab of an issue, you can drop comment badges on any area of the image and attach a comment. This is great for having point-of-interest discussions. However, as feedback is given and you upload new revisions, sometimes you need to move the badge to a new spot. This release lets you drag badges around. Now you can:
>
> - Drag the comment badge around after you drop it.
> - Move someone else’s badge over to fit yours.
> - Move the badges to match a new Design after you make a layout revision.
Design Management[Automatically bring in artifacts from cross-project jobs](https://docs.gitlab.com/ee/ci/yaml/#needsproject):
> You can now specify that a job in a project depends on the latest artifact produced by a job in another pipeline, making it much easier to set up cross-project pipelines that have artifact dependencies on each other.
>
> As an example, you might have a pipeline that builds an executable binary. Before this update, you had to rebuild all of the libraries the binary depended on every time you built the binary, even if the library didn't change. This was a waste of time and computing power, and the workarounds required using a brittle mix of API keys, cURL, and secure variables. Now, by specifying `artifacts: true` on your `needs:` job, you can pull the artifact generated by the library pipeline and use it in your final executable pipeline without the need to rebuild.
Continuous Integration (CI)[Build, publish, and share packages to the GitLab NuGet (.NET) Repository](https://docs.gitlab.com/ee/user/packages/nuget_repository/):
> For any organization delivering software, providing teams with an easy and secure way to manage dependencies is critical. Package managers, such as NuGet for C# .NET, provide a standardized way to share and version-control these libraries across projects.
>
> In GitLab 12.8, we are proud to offer NuGet repositories built directly into GitLab. Developers now have an easier way to publish their projects' NuGet packages. All you have to do is set the NuGet remote to the GitLab Package Registry and start uploading, installing, and deleting packages today.
Package Registry[GitLab metadata is now available in the Package Registry user interface](https://docs.gitlab.com/ee/user/packages/):
> We learned from a recent round of [user research](https://gitlab.com/gitlab-org/uxr_insights/issues/623) that users navigate to the Package Registry UI to verify which version of a package they should use or verify that their pipeline built it correctly. However, since we did not display any information in the user interface about how a package was built, users were forced to navigate between several different areas of the application.
>
> In GitLab 12.8, we are excited to announce that packages built via GitLab pipelines will now include `pipeline_id`, `branch`, and `commit` in the Package Registry user interface. This will help users understand how a package was built and troubleshoot much easier when something goes wrong!
Package Registry[GitLab NPM Registry to support NPM distribution tags](https://docs.gitlab.com/ee/user/packages/npm_registry/#npm-distribution-tags):
> To verify that their NPM package was uploaded or to look up the correct version of a package, users would like to use package metadata. NPM tags can be used to provide an alias instead of version numbers, making it easier to discover packages. For example, a project might choose to have multiple streams of development and use a different tag for each stream, such as `stable`, `beta`, `dev`, or `canary`.
>
> In GitLab 12.8, we are excited to announce that we now support NPM distribution tags in the GitLab NPM Registry. You can now add, remove, and list tags associated with any package hosted in their registry, making it both faster and easier to find and discover packages.
Package Registry[Automatically stop environments after a specified period](https://docs.gitlab.com/ee/ci/environments/index.html#environments-auto-stop):
> You can now set the expiration time to stop environments automatically after a certain idle period. This is especially useful for short-lived environments (such as the ones used for Review Apps) to avoid wasting resources. It can be set up through a new entry in `.gitlab-ci.yml`, for example, `auto_stop_in: 1 week`, and can be manually overridden from the GitLab UI. Users can also disable auto-stop by pinning their particular environment through the UI and keeping the environment running regardless of the setting.
>
> By preventing a situation where many stale environments are laying around, you don’t waste infrastructure resources by keeping them running. You also gain back development time that would otherwise be spent manually stopping environments.
Review Apps, Release Orchestration[Project import and exports are faster and more reliable](https://docs.gitlab.com/ee/user/project/settings/import_export.html):
> GitLab 12.8 includes significant improvements to how projects are imported and exported, resulting in much faster execution times and improved reliability.
>
> Project exports are now four times faster to complete, with 80% reduction in memory footprint. Previously, large projects could fail to export due to exceeding the memory limitations of the export job. With the reduced footprint, these jobs are now much more likely to succeed.
>
> Project imports are approximately 50% faster, due to a significant reduction in database calls. In the future, we plan to reduce the memory required for imports, by switching to [newline-delimited JSON](https://gitlab.com/gitlab-org/gitlab/issues/197171).
Importers[Enable Review Apps via a code snippet](https://docs.gitlab.com/ee/ci/review_apps/#enable-review-apps-button):
> We want to make Review Apps easy to set up even if you already have a functioning `.gitlab-ci.yml` file. A new **Enable Review Apps** button has been added to the environments page; if you are using Kubernetes and want to enable Review Apps, this will show you the YAML snippet that needs to be added to your `.gitlab-ci.yml`.
Review Apps[Geo improved license banner](https://docs.gitlab.com/ee/administration/geo/index.html) (self-managed only):
> Geo is only available at the Premium and Ultimate tier. Previously, when you tried to enable Geo in the administrator interface using a Starter or Core license, we just told you that the license was invalid - not very helpful! We now provide a clearer message stating which license you are using, which one you need to use Geo, and we also provide a link to manage your license.
>
> We hope you give Geo a try!
Geo-replication, Disaster Recovery[PostgreSQL 11 is now available in Omnibus GitLab](https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html) (self-managed only):
> The Omnibus GitLab package now includes PostgreSQL 11. The PostgreSQL 11 release includes enhancements to partitioning and other performance improvements that we will be building upon in GitLab 13.x to increase its overall speed and responsiveness. PostgreSQL 11 has been fully tested with Omnibus GitLab for new installs and upgrades, including HA configurations. [Testing with Geo is in progress](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4971).
>
> Upgrades to PostgreSQL 11 are opt-in for GitLab 12.8. For instructions on upgrading, see the [upgrade notes](https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html). New installs, and automatic upgrades from 9.6, will still default to PostgreSQL 10. PostgreSQL 11 will become opt-out in GitLab 12.10 and the minimum required PostgreSQL version in GitLab 13.0. For more details about GitLab's PostgreSQL 11 roadmap, see [the epic for adding support for PostgreSQL 11](https://gitlab.com/groups/gitlab-org/-/epics/2414).
>
> We encourage administrators of instances not using Geo to upgrade to PostgreSQL 11 at their earliest convenience to benefit from performance improvements and to prepare for the [removal of PostgreSQL 9.6 and 10.x in GitLab 13.0](#planned-removal-of-postgresql-9.6-and-10.x-in-gitlab-13.0).
Omnibus Package[Display Kubernetes namespace on the job page](https://docs.gitlab.com/ee/ci/pipelines/index.html):
> When a CI/CD job deploys to a Kubernetes [environment](https://docs.gitlab.com/ee/ci/environments/index.html), the job detail page will now display the Kubernetes namespace used for that deployment. You can use the detail page to verify workloads are deployed to the correct destination.
Kubernetes Management[Install more Kubernetes applications using CI/CD templates](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha):
> Installing Kubernetes applications [using GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha) provides a great way to customize applications before installation.
>
> In GitLab 12.8, new templates are available for installing [JupyterHub](https://docs.gitlab.com/ee/user/clusters/applications.html#install-jupyterhub-using-gitlab-ci) and the [Elastic Stack](https://docs.gitlab.com/ee/user/clusters/applications.html#install-elastic-stack-using-gitlab-ci) using GitLab CI/CD. Installing applications via GitLab CI/CD will additionally enable version control and access control to the installed charts.
Kubernetes Management[Documentation for using earlier Knative Versions](https://docs.gitlab.com/ee/user/project/clusters/serverless/#using-an-older-version-of-gitlabktl):
> As Knative approaches version 1.0, many GitLab users need to build older versions of Knative as many kinks in the Knative upgrade process have not yet been ironed out. A problem arises because new versions of `gitlabktl` only support a specific version of Knative because of API changes. Because GitLab Serverless is in alpha, we've chosen not to support backward compatibility. As we shipped updates, each version of `gitlabktl` has only supported a specific version of Knative. While this strategy keeps development simple and lets us iterate quickly, it has made it painful to update GitLab, because we were forced to update Knative as well.
>
> The solution to this problem is to use a pinned version of `gitlabktl`. While this has always been possible, it hasn't been easy to figure out. We've now added a clear set of instructions to our docs to aid in discoverability and execution.
Serverless[Omnibus improvements](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html) (self-managed only):
> Omnibus GitLab now includes PostgreSQL 11 as an opt-in version of PostgreSQL. See [the main release post announcement](https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#postgresql-11-is-now-available-in-omnibus-gitlab) for more details.
>
> GitLab 12.8 includes [Mattermost 5.19](https://mattermost.com/blog/mattermost-5-19-webex-plugin-faster-development-cycles-with-gitlab-1-click-mattermost-install-on-digitalocean/), an [open source Slack-alternative](https://mattermost.com/). This release of Mattermost includes faster development cycles with GitLab, a Webex plugin, 1-click Mattermost install on DigitalOcean, and [security updates](https://mattermost.com/security-updates/). We recommend upgrading from earlier versions.
Omnibus PackageBug fixes
> Some of the notable bug fixes in GitLab 12.8 are:
>
> - [Handling LFS objects for fork networks](https://gitlab.com/gitlab-org/gitlab/issues/20042)
> - [Initialization order issue with the Geo database](https://gitlab.com/gitlab-org/gitlab/issues/199672)
[Performance improvements](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.8)
> We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/gitlab-the-product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
>
> In GitLab 12.8 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.8 are:
>
> - [Remove N+1 from user notification settings](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22845)
> - [Remove Gitaly calls from Todos page](https://gitlab.com/gitlab-org/gitlab/issues/39509)
> - [Add foreign key constraints to Epics table](https://gitlab.com/gitlab-org/gitlab/issues/32326)
> - [Fix blobs search API degradation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24607)
> - [Application limit for ES indexed field length](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24345)
> - [Optimize issue search when sorting by due date and position](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24217)
> - [Optimize issue search when sorting by weight](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24208)
[Dark syntax highlighting theme for Web IDE](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme):
> GitLab has long supported alternative [syntax highlighting themes](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme) for use when browsing files in the repository or viewing diffs during the code review process. However, our code editor areas have not supported the use of this preference despite being the most requested feature for the Web IDE.
>
> The Web IDE now supports the Dark syntax highlighting preference in the code area. We've started with this theme, as it's the most widely used one beyond our default, but we'll continue to [expand our support](https://gitlab.com/groups/gitlab-org/-/epics/2389) for syntax highlighting preferences in the Web IDE. We'll also be working on expanding the [dark theme to the rest of the Web IDE](https://gitlab.com/gitlab-org/gitlab/issues/199664), including the file tree and sidebars.
Web IDE[S/MIME Signature Verification of Commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/x509.html):
> Every commit in a Git repository has an author, but this is not verified by Git and means that it is easy to create commits that appear to be authored by someone else. Commit signing allows you to prove that you are the author of the commit. This is important for sensitive projects and in some commercial environments.
>
> In Git 2.19, OpenGPG signing and verification support was extended to include support for S/MIME using X.509 certificates, because managing these certificates is more friendly for large organizations.
>
> GitLab now also supports S/MIME Signature Verification of commits, thanks to [Roger Meier](https://gitlab.com/bufferoverflow) from Siemens! Further thanks go to [Henning Schild](https://gitlab.com/henning-schild), also from Siemens, for [contributing this feature to Git](https://public-inbox.org/git/[email protected]/) in the first place!
Source Code Management[Enable Git protocol v2 for HTTP](https://docs.gitlab.com/ee/administration/git_protocol.html):
> We've re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.
>
> Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git's [wire protocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html) which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.
>
> Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. `git fetch origin master`) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data.
>
> Git protocol v2 is supported from Git 2.18.0 and is opt-in. To enable it, run `git config --global protocol.version 2`. Git protocol v2 over SSH is not yet enabled. Follow this [issue](https://gitlab.com/gitlab-org/gitlab-shell/issues/273) for updates.
Gitaly[Faster repository browser](https://docs.gitlab.com/ee/user/project/repository/):
> Exploring the source code of a project you've just discovered, or a project which you contribute to is now faster. In GitLab 12.8, when browsing between directories, the file list and commit data are updated without reloading the entire page, which eliminates unnecessary page loads.
Source Code Management[Smarter Git packfile reuse](https://public-inbox.org/git/[email protected]/):
> In GitLab 12.8, we are including a patched version of Git 2.24 in GitLab Omnibus with improvements to Git packfile reuse.
>
> When a client fetches or clones, it is more efficient for the server to respond by reusing existing packfiles as much as possible. The improvements implement a new smarter algorithm for reusing packfiles that makes a better compromise between the cost to serve a clone or a fetch, and the quality of the resulting packfile.
>
> Thank you [Peff](https://github.com/peff/) and GitHub for sharing this improvement, and Jonathan Tan (Google) for your help reviewing! We hope the [patches](https://public-inbox.org/git/[email protected]/) land in Git 2.26.
Gitaly[Tab width user preference](https://docs.gitlab.com/ee/user/profile/preferences.html#tab-width):
> Tabs, in contrast to spaces, are [more than a matter of preference](https://wiki.c2.com/?TabsVersusSpaces) for some. For those who use tabs, the correct tab width is no trifling matter. Particularly for C and Go projects, where tabs are most common, it is important that tab width can be configured to match local preferences for the best code review.
>
> GitLab now provides a **Tab width** user preference, used when viewing code including diffs, CI logs, and rendered code blocks in Markdown.
>
> Thank you [Alexander Oleynikov](https://gitlab.com/0leynikov) for your [contribution](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22063)!
Source Code Management[Enable Git delta islands core](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/delta_islands.md):
> Depending on the structure of a Git repository's packfile on disk, cloning can be CPU- and memory-intensive because Git may need to build and compress a packfile on the fly. Extreme CPU and memory use can occur when a large repository is cloned many times simultaneously, for example during a parallelized CI pipeline. However, if you trigger packfile reuse, instead of constructing the response on the fly, Git streams the packfile directly from disk, eliminating most CPU and memory usage of the clone.
>
> In GitLab 12.8, when repacking repositories, a [delta island core](https://gitlab.com/gitlab-org/git/blob/f1d4a28250629ae469fc5dd59ab843cb2fd68e12/Documentation/config/pack.txt#L35) is created that contains all the reachable branches and tags so that packfile reuse is triggered when cloning a Git repository. GitLab performs repacks automatically for active repositories, but they can also be triggered manually by clicking **Run Housekeeping** in the projects General Settings. Note, when using a shallow clone strategy for CI, packfile reuse will not be triggered.
Gitaly[Merge Request changes are loaded progressively](https://docs.gitlab.com/ee/user/project/merge_requests/):
> Merge Requests, particularly the **Changes** tab, is where source code is reviewed and discussed. Previously, as proposed changes became larger, the diff would load slowly and couldn't be read until fully loaded.
>
> In GitLab 12.8, the file changes list loads immediately, and the diffs are loaded progressively so that you can begin reading the diff almost immediately rather than waiting for the page to load fully.
Code Review[Automated accessibility scanning of Review Apps](https://docs.gitlab.com/ee/user/project/merge_requests/accessibility_testing.html):
> Accessibility of web pages and applications is a growing concern for software developers today. Unfortunately, accessibility testing is often an afterthought occurring late in the software development process. It's typically a manual and inconsistent process if it's done at all. Development teams often lack clear requirements from Product Managers or Product Designers outlining accessibility standards to follow when building an application.
>
> Starting in GitLab 12.8, you will be able to automatically scan and get a report of accessibility issues in your Review App. This saves development time by bringing the feedback loop of accessibility issues much closer, so you can have the most impact on making the application accessible for all users. As a first step, you can download a report for every Merge Request.
>
> We see this as a solid foundation to build on in the accessibility testing category. We are looking forward to feedback from customers on our Accessibility Testing category vision.
Accessibility Testing[Allow-failure action is now available in new rules syntax](https://docs.gitlab.com/ee/ci/yaml/#rulesallow_failure):
> Expanding on our new rules syntax, it is now possible to define pipeline rules that are allowed to fail. This gives users more flexibility when setting up their job behaviors and makes it easier to migrate additional projects to our new, more human-readable syntax.
Continuous Integration (CI)[Jobs in Directed Acyclic Graph (DAG) pipelines can be set up with no predecessors](https://docs.gitlab.com/ee/ci/yaml/#needs):
> Specifying an empty `needs:` array can be used to indicate to GitLab that there is no predecessor for that job and that it can always start immediately, regardless of what stage it is in. You can use this to set up more flexible relationships in a DAG pipeline, speeding them up and making them more efficient.
Continuous Integration (CI)[Extended log length in pipeline failure emails](https://docs.gitlab.com/ee/user/profile/notifications.html#notifications-on-issues-merge-requests-and-epics):
> The length of the log in pipeline failure emails has been increased from 10 to 30 rows, making it easier to see more of the trace and more likely that the complete error message is included in the email.
>
> Thanks to [Philipp Hasper](https://gitlab.com/PhilLab) for the contribution!
Continuous Integration (CI)[GitLab Runner 12.8](https://docs.gitlab.com/runner):
> Welcome to the 12.8 release of GitLab Runner. GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.
>
> Key highlights include:
>
> - [Kubernetes executor should expose services via HostAliases](https://gitlab.com/gitlab-org/gitlab-runner/issues/2229)
> - [Bump Go version to 1.13.7](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1819)
> - [Add support for X-GitLab-Trace-Update-Interval header](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1760)
> - [Support rate-limiting headers from GitLab API](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1728)
>
> You can find the full list of changes in GitLab Runner's [changelog](https://gitlab.com/gitlab-org/gitlab-runner/blob/12-8-stable/CHANGELOG.md).
GitLab Runner[Improved performance for the GitLab Container Registry garbage collection algorithm for S3](https://docs.gitlab.com/ee/administration/packages/container_registry.html#container-registry-garbage-collection):
> For organizations building many images across many projects, it is important to remove old, unused images and tags. The container registry garbage collection takes a long time to run and consumes resources inefficiently during the process. This makes it difficult for instances with large registries to run garbage collection and results in an increased cost of storage.
>
> In GitLab 12.8, we are excited to announce a significant improvement in the performance of garbage collection for instances using S3 for storage. These improvements optimize both the `mark` and `sweep` phase of the algorithm. While testing on 15 thousand images, the `mark` phase went from 25 minutes to 90 seconds! The `sweep` phase went from 20 minutes to 3 seconds! Read more on performance tests and benchmark optimization in the [merge request](https://gitlab.com/gitlab-org/container-registry/-/merge_requests/31).
Container Registry[Leverage policies to remove Docker images](https://docs.gitlab.com/ee/user/packages/container_registry/#expiration-policy):
> You build many Docker images as part of your pipelines, however, many of these images are only needed for a short time. Until now, you've had to rely on removing images via the [Container Registry API](https://docs.gitlab.com/ee/api/container_registry.html) or using the user interface. Both require effort. Wouldn't it be great to define a policy and have those unwanted tags removed automatically?
>
> In 12.8, we are excited to introduce Docker tag expiration policies for all new projects. This new feature allows you to identify a tag by name, select how many versions of the tag to keep, and define when it should be removed. For example, you can set up a policy that will remove all tag names that match a regex like the Git SHA, always keep at least five images, and remove any image that is older than 30 days.
Container Registry[Clean up corrupted Docker manifests during garbage collection](https://docs.gitlab.com/ee/administration/packages/container_registry.html#container-registry-garbage-collection):
> When running [garbage collection](https://docs.gitlab.com/ee/administration/packages/container_registry.html#container-registry-garbage-collection) to remove old, unused images, users have frequently run into an issue in which the process fails due to corrupted Docker manifests. To resolve this issue, administrators have had to manually remove the corrupted files from object storage, which is slow and risky.
>
> In 12.8, we are excited to announce that any corrupted manifests will now be deleted as part of the garbage collection process. If a bad link file (zero bytes in size or with an invalid checksum) is found during garbage collection, instead of stopping the garbage collector, it will log a warning message and ignore it. Blobs related with invalid link files will be deleted in the `sweep` stage if those blobs are not associated with another valid link file. This update makes the garbage collection process more reliable and efficient.
Container Registry[Resolve Docker garbage collection issues for GitLab Container Registries hosted on DigitalOcean S3](https://docs.gitlab.com/ee/administration/packages/container_registry.html#container-registry-garbage-collection):
> There is a known Docker issue where Ceph-based storage for all requests with absolute URI impacts the Docker garbage collection process. Since DigitalOcean uses Ceph, it prevents users from running garbage collection if they are using DigitalOcean for storage. This results in higher storage costs for those users.
>
> In GitLab 12.8, we resolved this issue by updating the driver for [Ceph](https://ceph.io/ceph-storage/) to support the latest version of the API. This allows any organization using DigitalOcean for storage for their GitLab Container Registry to run garbage collection and lower their cost of storage.
Container Registry[Improved performance of the delete API for the Container Registry frontend](https://docs.gitlab.com/ee/user/packages/container_registry):
> The GitLab Container Registry user interface allows you to view, discover and manage your project's images. The problem is that deleting a tag has been the worst-performing action on GitLab.com, with some requests taking up to 60 seconds to complete. This has resulted in slow page load times and an increased number of support requests.
>
> In GitLab 12.8, we are excited to announce that we have improved the performance of this function by ~70%. This will improve page load times and reliability.
Container Registry[Automatically close issues when the related Sentry error resolves](https://docs.gitlab.com/ee/operations/error_tracking.html#resolving-errors):
> Managing errors in your application is tough enough without needing to also remember to close the GitLab issue after fixing the error. GitLab issues now close automatically after the related Sentry error is resolved. It eliminates the extra manual work and prevents confusion over which issues are still active.
Error Tracking[Scale metrics chart](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#area-or-line-chart):
> The y-axis value on the metric chart had previously always started from zero. This made it difficult for users to detect minor changes on the metric charts. Starting with version 12.8, the y-axis values will automatically scale according to the data.
Metrics[Duplicate a dashboard including custom metrics](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#duplicating-a-gitlab-defined-dashboard):
> Previously, duplication of dashboards included only default metrics. With this new enhancement in 12.8, custom metrics are now included when cloning a default dashboard with both custom and default metrics.
Metrics[Searchable environment in metrics dashboards](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#select-an-environment):
> Searching for a specific environment could get cumbersome when you have many of them. You can now quickly find the environments you want to see in the metrics dashboard with the new search bar in the dropdown menu.
Metrics[GitLab self-monitoring project](https://docs.gitlab.com/ee/administration/monitoring/gitlab_self_monitoring_project/) (self-managed only):
> GitLab administrators can now gain insights into the health of their GitLab instances, using a new base project which will be added under the "GitLab Instance Administrators" group. Created for visualizing and configuring key metrics to monitor your GitLab instance.
Metrics[Column charts for Metrics Dashboard](https://docs.gitlab.com/ee/operations/metrics/dashboards/panel_types.html#column-chart):
> When it comes to visualizing metrics, users often like to choose different types of visualization for different metrics. To help achieve that, we've added column charts as a new visualization option on your monitoring dashboard so you can display your data how you want.
Metrics