GitLab.org/GitLab: Release v12.6.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.6
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Require rotation of personal access tokens](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limiting-lifetime-of-personal-access-tokens) (self-managed only)
> Security-minded organizations have historically used regular rotation of
> credentials to limit the amount of time an attacker has access to a
> system through a compromised secret. While guidelines from organizations
> like [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) no longer
> recommend periodic rotation, we're adding the ability to enforce regular
> rotation of [personal access
> tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-tokens)
> due to their inherent lack of 2FA protection, customer demand, and
> importance in certain compliance frameworks (e.g.
> [PCI](https://pciguru.wordpress.com/2019/03/11/the-new-nist-password-guidance/)).
>
> With this change, an instance administrator can configure a maximum
> lifetime for generated personal access tokens. Applying a limit will
> expire existing tokens, which must be regenerated and adhere to the
> newly applied expiration requirement. After a token's expiration date
> has passed, it must be regenerated.
[Simplify user management with Personal Access Token and SSH key inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html) (self-managed only)
> As your GitLab self-managed instance grows, so too does your need for
> [compliance
> controls](https://about.gitlab.com/direction/govern/compliance/compliance-management/).
> As more users, groups, subgroups, and projects are added, your instance becomes inherently more complex. You need visibility into who has access to your instance in an aggregate view in order to manage your instance's risks and compliance.
>
> To support customers in this effort, we've introduced an
> [MVC](https://about.gitlab.com/handbook/values/#minimal-viable-change-mvc)
> for an inventory of PAT and SSH credentials. This view provides
> important details to administrators, such as the owner, type, and scope
> of each credential. It will also show when a credential is set to expire
> and when it was last used.
[Quickly understand your at risk projects with Project Security Grades](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#group-security-dashboard)
> We're excited to announce a new "security grades" feature in Group
> Security Dashboards. In addition to the existing vulnerabilities list
> and history, this new panel on the Group Security Dashboard lets you
> know which projects are most affected/at risk so you can go right to the
> projects that need the most immediate attention.
>
> The severity of any detected vulnerabilities on a project is used to
> create a simple A through F letter grade. Projects are grouped by
> grade, so you can easily see which have no unresolved vulnerabilities
> (grade A) through to those with at least 1 critical (grade F).
[View your Security and Compliance config from a centralized interface](https://docs.gitlab.com/ee/user/application_security):
> We are excited to announce a new ability to view the Secure scanners.
> You will see a new `Configuration` option under the `Security and
> Compliance` section on the left navigation. This UI will show you which
> security scans are available, what scans have been configured, and
> provide clear links to the relevant scanner documentation.
>
> **Note:** as this is the initial
> [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)
> of this new feature, there currently is no advanced configuration, so
> you cannot disable or enable the scans from this screen.
> {: .note}
configuration[Support for PHP added in License Compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html#supported-languages-and-package-managers)
> If you are using PHP in your project, you can now use our [License
> Compliance](/direction/secure/composition-analysis/license-compliance/)
> feature. Please note this is at the `experimental` support level. We
> added support for PHP, specifically focusing on composer-based projects
> (using `composer.lock`).
[Dependency Scanning improvement for Python projects](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-variables):
> If your Python dependencies are stored in a file other than the regular
> `requirements.txt`, with GitLab 12.6, you can now set the requirements
> file with the `PIP_REQUIREMENTS_FILE` variable.
Dependency Scanning[Dependency Scanning for Java Gradle projects](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers)
> For users with [Java Gradle](https://gradle.org/) projects, you can now
> leverage our [Dependency
> Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
> features.
[SAST Support for React framework (JavaScript)](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> If you have projects written using the React framework for JavaScript,
> you can now use our
> [SAST](https://docs.gitlab.com/ee/user/application_security/sast/)
> scanners to find any security issues.
SAST[SAST for Kubernetes manifests](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> Kubernetes manifests can now be checked for sensitive data like secrets and privileges, by using [`kubesec`](https://kubesec.io/).
SAST[Dependency scanning for Scala projects using the sbt package manager](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> With GitLab 12.6, we have added support for Scala with the [sbt package manager](https://www.scala-sbt.org/)
> in Dependency Scanning. You are now able to scan your Scala projects for potential vulnerabilities.
Dependency Scanning[SAST compatible with private dependencies](https://docs.gitlab.com/ee/user/application_security/sast/#using-environment-variables-to-pass-credentials-for-private-repositories):
> Projects that have dependencies that are hosted in a private repository
> now have a way of propagating authentication credentials for the private
> repository into the SAST container to have them used by the analyzing
> command.
SAST[Access Pod Logs Directly from the Operations Tab](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html)
> Previously, there wasn't an easy way to navigate directly to your pods'
> logs view. In order to get to them you had to navigate to your project's **Environments** tab
> underneath **Operations**, select the desired environment, and click the
> relevant pod. Now, with GitLab 12.6, viewing Pod Logs is easier than
> ever! Simply click on the **Pod Logs** tab underneath **Operations**.
[Maintain a consolidated commit history with squash-and-merge in Merge Trains](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/):
> [Squash-and-Merge](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html)
> allows you to combine all your merge request’s commits into one so you
> retain a clean history in the default branch while preserving the
> entire commit history in the merge request. In this release, we
> added squash support to Merge Trains, which allows running a build
> on the result of the merged code prior to merging, as a way to keep
> master green. The combination of these two features will ensure that
> master is always green while attaining a consolidated commit history.
Continuous Delivery, Merge Trains[Protect your project data with soft deletion for projects](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#project-deletion-adjourned-period)
> Currently, deleting a project in GitLab through the UI or [API](https://docs.gitlab.com/ee/api/projects.html#remove-project)
> is immediate, irreversible, and unrecoverable without restoring from a backup. This has the potential to result
> in unintentional data loss, which is a worst-case scenario for the team.
>
> To reduce this risk, GitLab 12.6 introduces soft deletion for projects. Instead of immediate removal of the project
> or group, the resource will be marked for deletion and removed after a configurable soft deletion time-frame. While the
> default time-frame is 7 days, instances wishing to retain immediate deletion can set this to 0.
[Control rollout of Feature Flags based on UserID](https://docs.gitlab.com/ee/operations/feature_flags.html#user-ids):
> You can now define different userID targets for your feature flags per
> environment. The value that is gained here is that with this combination
> you can target different users on production than staging (or others)
> which allows you total control on how, where and to whom your Feature
> Flag will be toggled.
Feature Flags[Warning for skipping Merge Trains](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/#immediately-merge-a-merge-request-with-a-merge-train):
> When users choose **Merge Immediately** for their merge request, this
> delays all the merge requests in the Merge Train. Users were
> unintentionally doing this, unaware of the negative effect caused to the
> rest of the merge requests. Although we still allow urgent merge
> requests to skip the line, we added a warning as another layer of
> protection by explaining that this action will negatively impact others.
Continuous Delivery, Merge Trains[Remove need for client-based authorization with Visual Review Tools](https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-reviews-starter)
> In GitLab 12.0, we introduced [Visual Review
> Tools](https://about.gitlab.com/releases/2019/06/22/gitlab-12-0-released/#visual-reviews)
> to allow users to provide feedback on merge requests from the Review App
> itself.
>
> In GitLab 12.6, we simplified usage of the tool by removing the need to
> create a personal access token to provide feedback.
[Manage C/C++ packages via Conan within GitLab's Package Registry](https://docs.gitlab.com/ee/user/packages/conan_repository/)
> For any development organization, having an easy and secure way to
> manage dependencies is critical. Package management tools, such as Conan
> for C/C++ developers, provide a standardized way to share and version
> control these libraries across projects.
>
> In GitLab 12.6, we are proud to offer Conan repositories built directly
> into GitLab. Developers can now publish their packaged libraries to
> their project’s Conan repository. Simply set the Conan remote to the
> GitLab Package Registry and start uploading, installing, and deleting
> packages today.
[API endpoint to list the packages of a group](https://docs.gitlab.com/ee/api/packages.html#within-a-group)
> As part of the GitLab Package Registry, we provide an
> [API](https://docs.gitlab.com/ee/api/packages.html), to allow users to
> view, download, and delete packages. However, until recently the API was
> limited to a specific project, which prevented users from understanding
> which packages exist at the group level.
>
> In GitLab 12.6, we are excited to announce a new API endpoint that will
> allow users to list all packages at the group level.
[The GitLab NPM registry now supports installing dependencies](https://docs.gitlab.com/ee/user/packages/npm_registry/#npm-dependencies-metadata)
> In GitLab 12.6, we are very excited to announce that the NPM Registry
> now supports installing package dependencies. Until recently, running
> `npm install` would not work if the version was not included in the
> command. In addition, the command would not support installing the
> packages' dependencies. This was due to us not supporting the required
> NPM metadata, such as dependencies or tags.
>
> Moving forward, users can expect `npm install` to work as expected. Next
> we will work on [adding dependencies and tags to the Package Registry
> UI](https://gitlab.com/gitlab-org/gitlab/issues/12954).
[Filter issues and merge requests by Release](https://docs.gitlab.com/ee/user/search/#issues-and-merge-requests-per-project)
> Planning and managing a release can be complicated and being able to quickly
> find the related issues and merge requests makes it easier for teams to manage their work.
> In 12.6, we have added the capability to filter issues and merge requests by
> Release name. This will help find those items associated with a specific
> Release.
[Automated Release Evidence collection to support audits](https://docs.gitlab.com/ee/user/project/releases/#release-evidence)
> When development teams release code changes in many organizations, they are required
> to document the proof that they complied with the organization's processes and policies
> in their SDLC. Typically, this can be time consuming and inefficient. In 12.6, GitLab Releases
> now have a new **Evidence collection** entry in which you can find a snapshot of the Release's
> metadata in JSON format. This snapshot can be leveraged as a chain of custody to support review
> and compliance processes, such as audits.
[Collaborate more effectively on GitLab activity directly within Circuit](https://docs.gitlab.com/ee/user/project/integrations/unify_circuit.html)
> [Circuit by Unify](https://www.circuit.com/) is a collaboration and
> communication system used by many organizations. Similar to other notification
> integrations within GitLab, you can now configure webhooks to send
> selected notifications to a Circuit conversation. Notifications link back to your
> GitLab project, eliminating the need to context switch between an email client
> in order to keep up to date with GitLab activity.
>
> Thanks to [Fabio Huser](https://gitlab.com/fh1ch) for [your
> contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/19849)
[Entropy requirements for new user passwords](https://docs.gitlab.com/ee/security/password_length_limits.html) (self-managed only)
> Organizations need a way to secure their GitLab instances that aligns
> with their internal policies and procedures. Part of [securing
> GitLab](https://gitlab.com/groups/gitlab-org/-/epics/258) is enforcing a
> password policy. GitLab recently updated its own internal [password
> policy
> guidelines](https://about.gitlab.com/handbook/security/#gitlab-password-policy-guidelines)
> based on [NIST SP
> 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html). In this
> special publication, NIST advises on leveraging password length and
> complexity, but does not recommend password rotation or even requiring
> specific complexity rules (e.g. a specific number of special
> characters).
>
> Using NIST's guidance, GitLab is introducing a new setting within the
> Admin Area to specify a **minimum password length** that applies only to
> new passwords. This means any new account being created or any password
> being changed will be required to meet this minimum length requirement.
> By enabling customers to define a minimum password length, GitLab
> environments can become more secure and organizations can manage this
> policy across an instance for reassurance that passwords are compliant
> with internal policies.
[Filter members list for users with direct membership](https://docs.gitlab.com/ee/user/project/members/#inherited-membership)
> There are two ways to gain access to a private project or group: a)
> being directly added to that specific project or group or b) [inheriting
> a role from a parent
> group](https://docs.gitlab.com/ee/user/group/subgroups/index.html#membership).
> In GitLab 12.6, we're making it easier to understand the source of a
> user's membership by allowing filtering of the Members table
> specifically for direct members or inherited members.
>
> This is particularly useful for groups with [external
> users](https://docs.gitlab.com/ee/user/permissions.html#external-users)
> or instances using [groups for notifying teams of
> people](https://docs.gitlab.com/ee/user/group/#use-cases).
[ConvDev Index is now DevOps Score](https://docs.gitlab.com/ee/user/instance_statistics/dev_ops_score.html)
> As we invest further in analytics in GitLab, our features should align with commonly used
> terms. Conversational development is a useful concept, but GitLab is built around the
> language of DevOps.
>
> Directly referencing this term is especially helpful for organizations looking to track
> their adoption of DevOps best practices. We plan on
> [iterating on this feature](https://gitlab.com/gitlab-org/gitlab/issues/20601) further, but
> a first important step is a name change to reflect where we're going.
[Edit a release via the Releases page](https://docs.gitlab.com/ee/user/project/releases/#editing-a-release)
> In GitLab 12.6, we are adding the capability to edit Release titles and
> notes directly from the user interface, instead of using the GitLab API.
> This provides a faster and more intuitive method to edit releases.
[Official GitLab container with AWS client installed](https://docs.gitlab.com/ee/ci/cloud_deployment/index.html):
> Interacting with a major cloud provider such as AWS, Azure, or GCP is a core component of many delivery pipelines. But before you can automate your cloud interactions, you need to have an environment set up with the appropriate tools. Previously this was something you had to manage on our own, but starting in 12.6, GitLab will provide an official AWS Docker image that will allow you to run `aws` commands from your CI/CD pipelines. You can access a variety of AWS services using a Docker image that is maintained and kept up-to-date by GitLab.
>
> Delivering an official image is also the first step in [supporting AWS deploys to EC2](https://gitlab.com/groups/gitlab-org/-/epics/2351). It’s part of our broader plan to include [native support for deploying to multiple cloud providers](https://gitlab.com/groups/gitlab-org/-/epics/1804). We hope to see community contributions for additional cloud providers using this model of pre-built images with included scripts hosted in the [official GitLab Cloud Deploy container registry](https://gitlab.com/gitlab-org/cloud-deploy/container_registry).
Continuous Delivery[Delete related resources when removing Kubernetes clusters](https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html#removing-integration):
> Re-using clusters across instances, groups, or projects can be time
> consuming as operators must ensure that all related cluster resources
> (such as namespaces, roles, bindings, etc.) are removed from the cluster
> prior to linking it to a new entity. Often times, operators choose to
> destroy a cluster and create a new one to avoid manual deletion of
> resources.
>
> GitLab now provides the ability to remove all the related cluster
> resources upon removal, making it fast and easy to re-use clusters
> elsewhere.
Kubernetes Management[Customize Kubernetes namespace per environment](https://docs.gitlab.com/ee/ci/environments/index.html#configuring-kubernetes-deployments):
> When you use GitLab's Kubernetes integration, it automatically creates a
> namespace to serve as a deploy target for GitLab CI/CD. This makes it
> easy to get started with Kubernetes. However, if you already have a
> cluster with an existing set of namespaces, more than likely you will
> want to designate one of those existing namespaces as a GitLab deploy
> target.
>
> Now with GitLab 12.6, you are able to specify a custom namespace for
> each CI environment in your `.gitlab-ci.yml` file allowing you to deploy
> to namespaces that existed before you connected your Kubernetes cluster
> to GitLab. Initially, this feature is only available for non-managed
> clusters but does support dynamic environments (e.g. for use in review
> apps).
Kubernetes Management[Automatically use customized deploy values file in Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#workers):
> Auto DevOps' Auto-Deploy now allows for bulk configuration of its Helm
> chart values. By simply adding a `.gitlab/auto-deploy-values.yaml` file
> to your project, Auto DevOps will automatically detect it and use its
> values for deployment. This eliminates the need to create multiple
> `HELM_UPGRADE_EXTRA_ARGS` environment variables for your project and has
> the added benefit of version control.
Auto DevOps[Allow clearing of cluster cache to avoid getting out of sync](https://docs.gitlab.com/ee/user/project/clusters/#clearing-the-cluster-cache):
> We often need to carry out actions on Kubernetes clusters directly, for
> example while troubleshooting or fine tuning. Making changes to
> Kubernetes resources directly in the cluster can put GitLab out of sync
> with the cluster so it won't recreate resources because it assumes they
> already exist.
>
> Starting with GitLab 12.6, the Kubernetes integration will offer the
> option to clear the local cache of namespace and service accounts,
> allowing the next CI job to re-create them when necessary.
Kubernetes Management[Cloud Run for Anthos support in GKE Kubernetes clusters](https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html#cloud-run-on-gke)
> When creating a Kubernetes cluster via GitLab's GKE integration, users
> can now optionally enable "Cloud Run on Anthos" with a single click. GKE
> will automatically provision the cluster with Knative serving, Istio,
> and HTTP load balancing, and Cloud Run will take care of keeping the
> cluster upgraded. When installed, users can continue to take advantage
> of the features offered by [GitLab
> Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
> to deploy Knative services with minimal configuration.
>
> Note: We announced Cloud Run for Anthos support in GitLab 12.4, however
> we had to switch it off later due to compatibility issues. We've been
> working hard to ship a future-proof integration.
[Install Kubernetes applications using CI template](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha)
> Installing Kubernetes applications [using GitLab CI](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha)
> provides a great way to customize Helm charts prior to installation.
> In order to make it easier to get started, we have added a
> [CI template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Managed-Cluster-Applications.gitlab-ci.yml)
> with all the currently supported applications. In addition to this template, we
> have created an [example cluster-management project](https://gitlab.com/gitlab-org/cluster-integration/example-cluster-applications)
> containing all the necessary items required to get started. Simply import and mirror
> this project to get all the latest supported apps.
[Knative 0.9 support](https://docs.gitlab.com/ee/user/project/clusters/serverless/):
> Starting with GitLab 12.6, when you install Knative as a GitLab Managed App, version 0.9 will be installed. This is a major upgrade in the life of Knative. [Knative Serving](https://knative.dev/docs/serving/)
> has received its final v1 API endpoints and is considered to be production ready, but the `beta` and `alpha`
> endpoints are still available. Given the stable API, this upgrade provides some level of forward-compatibility too.
Serverless[Group Webhooks are now editable](https://docs.gitlab.com/ee/user/group/#advanced-settings):
> Group Webhooks are now editable! Previously, it was only possible to
> create and delete them, so making a change to a webhook required you to
> delete the webhook and start over. This addition adds the ability to
> edit these in the UI, saving you time and effort when setting up your
> webhooks.
integrations[Webhook logs now available for CI integrations](https://docs.gitlab.com/ee/user/project/integrations/project_services.html):
> To assist users in troubleshooting CI integrations, we've added a log of
> recent events to the integration configuration pages. This log is
> available on the integrations settings pages for Jenkins, Packagist,
> Team City, DroneCI, Buildkite, and Bamboo. This new section lists the
> events that have triggered this integration in the last two days.
>
> This is particularly valuable when you are trying to troubleshoot a
> failing integration, as previously there was no place in the UI directly where these
> errors were displayed. Now, you'll have easy access to understand what
> has failed (or is currently working!) and why.
integrations[Jira issue links are now optional](https://docs.gitlab.com/ee/integration/jira/issues.html#disabling-comments-on-jira-issues):
> When a user has GitLab [integrated with Jira](https://docs.gitlab.com/ee/integration/jira/), comments are posted in Jira
> when activity happens in GitLab. This addition allows a user to [disable
> those comments](https://docs.gitlab.com/ee/integration/jira/issues.html#disabling-comments-on-jira-issues) from the configuration page on a per-integration basis.
>
> This is valuable for many users who don't want to see the comments, but
> still want to automatically link their Jira issues to their GitLab
> projects. Additionally, some users have noted use cases where there are
> Jira users who _should not have visibility_ of activity on the
> repository for confidentiality reasons. Having more fine-grained control
> over what content is posted to these comments is valuable for both of
> these cases.
integrations[Reduce GitLab memory usage with Puma (Experimental)](https://docs.gitlab.com/omnibus/settings/puma.html):
> In order to reduce the memory requirements of GitLab, we are migrating to
> [Puma](https://puma.io) from [Unicorn](https://bogomips.org/unicorn/).
> Puma supports multi-threading, which can reduce the memory footprint of
> GitLab by about 30%.
>
> Puma support is currently experimental, while we work to
> [enable Puma by default](https://gitlab.com/gitlab-org/gitlab/issues/31765)
> in 13.0. You can try it on a [test system today](https://docs.gitlab.com/omnibus/settings/puma.html),
> and report any issues [here](https://gitlab.com/gitlab-org/gitlab/issues/new?issue).
memory[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=12.6)
> We continue to improve the performance of GitLab with every release
> for GitLab instances of every size.
>
> Some of the improvements in GitLab 12.6 are:
>
> - [Enable HTTP caching for merge request comments polling](https://gitlab.com/gitlab-org/gitlab/merge_requests/20440)
> - [Reduce SQL queries when loading user avatars](https://gitlab.com/gitlab-org/gitlab/merge_requests/20847)
> - [Improve performance of SQL used in determining which Ci::JobArtifact records to sync to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/issues/10286)
> - [Remove an N+1 call rendering projects search results and fix false positive tests](https://gitlab.com/gitlab-org/gitlab/merge_requests/21626)
> - [Improve issues search performance on GraphQL](https://gitlab.com/gitlab-org/gitlab/merge_requests/20784)
> - [Preload group ancestor to avoid N+1](https://gitlab.com/gitlab-org/gitlab/merge_requests/20977)
> - [Improve .groups_user_can_read_epics performance](https://gitlab.com/gitlab-org/gitlab/merge_requests/20833)
> - [Remove stickyMonitor from diff_file_head.vue](https://gitlab.com/gitlab-org/gitlab/merge_requests/21076)
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 12.6 includes Mattermost 5.17.1, an [open source
> Slack-alternative](https://mattermost.com/). This version of
> Mattermost is focused on [quality
> improvements](https://docs.mattermost.com/administration/changelog.html#release-v5-17-1-quality-release).
[Disable group mentions](https://docs.gitlab.com/ee/user/group/#disabling-group-mentions):
> Mentioning a group with a large number of members can quickly lead to a
> high volume of unwanted notifications. To avoid this, you can now enable
> a group-level setting to prevent members from receiving notifications
> when the group is mentioned in an issue or merge request.
>
> Thanks [@fh1ch](https://gitlab.com/fh1ch) and Siemens!
Issue Tracking[Preview OpenAPI specifications](https://docs.gitlab.com/ee/user/project/repository/#openapi-viewer):
> The OpenAPI (previously known as Swagger) Specification is a popular
> standard for defining RESTful interfaces. However, reading the YAML
> source can be difficult. In GitLab 12.6, when viewing an `openapi.yml`
> file (or another supported filename), a rendered preview of the
> specification will be shown using the same interface as Swagger.
>
> Thank you [Roger Meier](https://gitlab.com/bufferoverflow) and Siemens
> for your [contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/21106)!
source code management[Deduplicate forks of internal projects](https://docs.gitlab.com/ee/administration/repository_storage_types.html#hashed-object-pools)
> Forking workflows makes it easy to contribute to any project by creating
> a copy of the upstream project to work on before opening a merge request
> to merge your changes into the upstream project. For popular projects,
> the server-side storage requirements needed for thousands of copies
> accumulate quickly and increase hosting costs.
>
> In GitLab 12.1, we introduced fork de-duplication for public projects,
> but many organizations missed out on the benefits because they primarily
> use internal projects. In GitLab 12.6, creating a fork of public or
> internal projects creates an object pool (if one doesn’t already exist)
> and uses `objects/info/alternates` to reduce the storage requirements of
> forks.
>
> Thanks [Brian Kabiro](https://gitlab.com/briankabiro) for your
> [contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/19295)!
[More easily navigate between tabs within Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/)
> Merge Requests are where source code is reviewed, tested, and discussed,
> but they can become unwieldy. Together, merge request descriptions,
> pipelines, and security scanning results often push the navigation tabs
> far down the page making them hard to find and difficult to access.
>
> In GitLab 12.6, the merge request navigation is now above the
> description, making it fast and easy to jump directly to the changes.
> Additionally, the description and widgets are now displayed on the
> **Overview** tab, providing improved focus and navigation throughout the
> merge request. Please share your feedback
> [here](https://gitlab.com/gitlab-org/gitlab/issues/36125).
[Real-time merge request widget updates](https://docs.gitlab.com/ee/user/project/merge_requests/)
> Before clicking Merge, if you make a final tiny fix by pushing or
> applying a suggestion, the merge button is disabled until you reload the
> page. This slows down the final stages of review when applying the final
> fixes. In GitLab 12.6, the merge request widget is now updated in
> real-time so that you can merge immediately or when the pipeline
> succeeds.
[Remove fork relationship when project visibility is restricted](https://docs.gitlab.com/ee/public_access/public_access.html#reducing-visibility)
> Forking workflows makes it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project.
>
> Previously, when the visibility of the root project in a fork network was **changed to be** restricted, the visibility of all the forks would be restricted. This could result in all forks of a public project suddenly becoming private if the root project was made private.
>
> In GitLab 12.6, instead of changing the visibility of all projects, the root project is simply removed from the fork network leaving all other projects unmodified. This is equivalent to the root project being deleted.
[GitLab Runner 12.6](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 12.6 today! GitLab Runner is the open source project
> that is used to run your CI/CD jobs and send the results back to GitLab.
>
> #### Changes include:
>
> - [Distribute arm64 binaries](https://gitlab.com/gitlab-org/gitlab-runner/issues/4870)
> - [Expose image to custom executor](https://gitlab.com/gitlab-org/gitlab-runner/issues/4357)
> - [Upgrade to Go 1.13](https://gitlab.com/gitlab-org/gitlab-runner/issues/4757)
> - [Fix regex for finding Virtualbox snapshot names](https://gitlab.com/gitlab-org/gitlab-runner/issues/3274)
> - [Removal of file locking](https://gitlab.com/gitlab-org/gitlab-runner/issues/5416)
>
> The list of all changes can be found in GitLab Runner's [CHANGELOG.](https://gitlab.com/gitlab-org/gitlab-runner/blob/12-6-stable/CHANGELOG.md)
[Inherited variables are now shown in project view](https://docs.gitlab.com/ee/ci/variables/#view-all-group-level-variables-available-in-a-project)
> When using a mix of project & group variables, it can be confusing to
> understand what group variables exist and how they may be related or
> conflict with project level variables. We have improved this by now
> showing the group (inherited) variables in the project variables page,
> making it easy to see what variables are coming from where.
[CI configuration outside of the repository](https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-ci-configuration-path)
> We have added the ability to specify the path of the `.gitlab-ci.yml` to
> an arbitrary URL, which allows you to store CI configurations in a
> repository other than the one being built. This can be very helpful for
> processing many repos the same way by pointing all of them to the same
> external `.gitlab-ci.yml` file. Efficiency is gained by having only one
> CI configuration file to update instead of maintaining individual
> configurations in each repository. Users that have a service that
> generates the configuration file dynamically would also benefit.
>
> This also makes it possible to protect configurations from unauthorized
> changes as the file can be hosted in a project with more fine-grained
> access control. We have updated our documentation to make it clear how
> to set this up.
[Improved integration between Error Tracking and Issue management](https://docs.gitlab.com/ee/operations/error_tracking.html#error-details):
> Triaging errors can be a manual and tedious process often completed by
> multiple individuals on your team. One team member may determine the
> Error is critical and go to create issues to fix the error. Starting in
> GitLab 12.6, Errors provide a link to open issues directly within the Error detail page, eliminating any confusion about
> whether an issue needs to be created.
>
> If an issue doesn't exist, you can now quickly create a GitLab issue from an generated Error when viewing that Error's detail page.
Error Tracking[Show recent searches when filtering errors](https://docs.gitlab.com/ee/operations/error_tracking.html#error-tracking-list):
> You've been there. You are troubleshooting an error you found in your
> application and have to frequently jump back and forth between searches
> through your error list. Starting in GitLab 12.6, you'll be able to
> quickly select recent searches when filtering errors.
Error Tracking[Add Sentry as a GitLab Managed App](https://docs.gitlab.com/ee/user/clusters/applications.html#install-sentry-using-gitlab-ci):
> If you're a user of GitLab's Error Tracking features, you value the
> ability to integrate with Sentry, the most popular open-source error
> tracking tool. Starting in GitLab 12.6, if you are unable to utilize a
> Sentry project on Sentry.io, you can deploy Sentry directly to a
> Kubernetes Cluster attached to your project or group. This will make it
> much quicker to get started with integrated error tracking in GitLab.
Error Tracking[Sort error list by first seen, last seen and frequency](https://docs.gitlab.com/ee/operations/error_tracking.html#error-tracking-list):
> Errors are often plentiful, noisy, and challenging to dig through to
> find the important ones which are impacting your users. Starting in
> GitLab 12.6, as you view a list of Sentry errors in GitLab, you'll be
> able to sort those errors based on frequency and when an error was last
> and first seen.
Error Tracking