GitLab.org/GitLab: Release v13.7.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.7
Released: 2020-12-22
License: MIT
Release Assets:
[SAML Group Sync for GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/#group-sync) (SaaS only):
> In GitLab 13.7, you can map a group in your identity provider to a GitLab.com group using SAML. Group memberships will be updated when a user signs in to GitLab through their SAML provider. This new functionality decreases the need for manual group assignment, reducing the group assignment workload for GitLab administrators. SAML group sync also improves the group member onboarding experience by reducing the need for access requests to GitLab group administrators.
Authentication and Authorization, Subgroups[SAML user provisioning for GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/#user-access-and-management) (SaaS only):
> Previously, users needed to complete a sign-up form as part of onboarding into a SAML-enabled group. In GitLab 13.7, we have introduced user provisioning for SAML-enabled groups. When a user signs in to a SAML-enabled group for the first time, a user account will be created for them automatically if there isn't an existing user with the same email. SAML provisioning improves the onboarding experience for new users and ensures that newly created accounts contain the right information.
Subgroups, Authentication and Authorization[Auto rollback in case of failure](https://docs.gitlab.com/ee/ci/environments/#auto-rollback):
> If you have a critical problem with a deployment, manual actions to fix it often take too long and lead to a degradation in production that impacts your users. Now, you can leverage an automatic rollback mechanism that reverts your deployment back to the last successful deployment. Also, when GitLab finds problems in production it automatically notifies you with an alert. This gives you peace of mind and precious development time to debug, investigate, and fix problems without causing downtime.
Continuous Delivery[API support for deployment frequency](https://docs.gitlab.com/ee/api/dora4_project_analytics.html):
> As part of the first iteration towards supporting [DORA4 metrics](https://gitlab.com/groups/gitlab-org/-/epics/4358) natively in GitLab, this release adds API support for deployment frequency on the project level. This enables you to monitor the efficiency of your deployments over time, find bottlenecks easily, and quickly take corrective action when necessary.
Continuous Delivery[Import requirements from external tools](https://docs.gitlab.com/ee/user/project/requirements/index.html#import-requirements-from-a-csv-file):
> Having all of your requirements in one place is crucial for efficient collaboration,
> so we are thrilled to announce that you can now import requirements from a CSV (comma-separated value) file!
>
> This feature will allow your whole team to collaborate on requirements from
> GitLab, but still allow you to interface with customers, suppliers, and external
> organizations with ease. Stay tuned for upcoming [requirement export functionality](https://gitlab.com/groups/gitlab-org/-/epics/4523).
Requirements Management[Special references for vulnerabilities](https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references):
> We introduced vulnerabilities as first-class objects in 12.10. Being a first-class object means each has a unique URL, allowing linking directly to any vulnerability's details. While a big improvement in visibility and consistency, references to vulnerabilities in issues and epics must still be copy-pasted as manual Markdown links. This makes sharing and referencing vulnerabilities in other areas of GitLab more cumbersome and less efficient than sharing other objects such as issues.
>
> Vulnerabilities can now be linked via special references. They are the first to use a new `[object_type:ID]` syntax that will eventually extend to other existing references. You can now quickly insert a link to a vulnerability from anywhere you might normally use a special reference such as an issue or merge request comment. For example, type `[vulnerability:123]` in an issue comment to insert a link to the vulnerability with ID 123 in the same project. You can also prefix the ID with a namespace or project to reference vulnerabilities outside the current project context.
Vulnerability Management[Set deployment traffic weight via the UI](https://docs.gitlab.com/ee/user/project/canary_deployments.html#how-to-change-the-traffic-weight-on-a-canary-ingress):
> In GitLab 13.7, you can change the canary weights directly from the Deploy Boards in the UI. You can change canary weights directly from `gitlab-ci.yml` and the API, but doing so in the UI lets you see the deployment and scale the pods up or down directly from the Deploy Boards. This gives you greater control over manual or timed incremental rollouts, and allows you to better mitigate risks.
Advanced Deployments[Support multiple manifest files in a project](https://docs.gitlab.com/ee/user/clusters/agent/repository.html) (self-managed only):
> In previous GitLab versions, the GitLab Agent for Kubernetes required users to collect all Kubernetes resources into a single manifest file. In this version of GitLab, the Agent can now grab Kubernetes manifests recursively from specified directories in your project. Your platform engineers can use a single repository to manage different clusters from one place, and can describe large deployments with a single Agent.
Kubernetes Management[Geo supports replicating Versioned Snippets](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only):
> Geo now supports replicating [Versioned Snippets](https://docs.gitlab.com/ee/user/snippets.html#versioned-snippets)
> to secondary nodes, allowing distributed teams to access them from the
> closest Geo node, which reduces latency and improves the overall user
> experience. Additionally, this data can also be restored from a
> secondary node when failing over to that node.
>
> We currently [don't support verification](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#limitations-on-replicationverification)
> of these assets, but future support is planned.
Geo-replication, Disaster Recovery[Group webhooks for members MVC](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#member-events):
> GitLab has made it easier for you to build user management automation with a webhook that is triggered when a new member is added to a group. Before, you had to run REST calls to identify new group members, which put unnecessary performance load on your GitLab instance.
Subgroups[Limit project and group creation for provisioned accounts](https://docs.gitlab.com/ee/user/group/saml_sso/index.html#configure-user-settings-from-saml-response):
> To reduce the risk of accidental exposure of intellectual property, GitLab administrators now have greater control over accounts provisioned by their group's SAML or SCIM integration. In the first iteration of these controls, administrators can prevent their users from creating groups or projects outside of groups to which they do not already belong.
Subgroups[Sort issues by the number of issues they are blocking](https://docs.gitlab.com/ee/user/project/issues/sorting_issue_lists.html#sorting-by-blocking-issues):
> While prioritizing a list of issues in GitLab, it's often important to determine the critical path and whether an issue is blocking other issues.
>
> With the current issue list, it is impossible to see which issues are blocking other issues. The only way to do so is to open each one and see the [list of blockers](https://gitlab.com/gitlab-org/gitlab/issues/2035) below the issue description, which is a very time-consuming task!
>
> As of 13.7, you can now use the filter for "Blocking" on any issue list, and you will see a list sorted by the number of blockers.
Issue Tracking[Integrate alerting tools with multiple HTTP endpoints](https://docs.gitlab.com/ee/operations/incident_management/alert_integrations.html#http-endpoints):
> Alert integrations are a critical part of your Incident management workflows, which is why it is important for you and your team to have granular control over the endpoints and authentication tokens. The last thing you want is to take down all of your alerting by resetting a single authentication token! Setting up a HTTP endpoint for each of your monitoring tools allows your team to separately manage each tool without impacting alerting from other tools.
Incident Management[Show deployment status on the Environments page](https://docs.gitlab.com/ee/ci/environments/#working-with-environments):
> Previously, you had no way of knowing that a deployment is in progress when viewing the Environments page. With deployment status and alerts now visible, the Environments page gives you an indication of what action you can take based on the deployment status (successful, failed, or in progress). For example, you might want to stop a deployment that is currently in progress, or roll back a finished deployment.
Continuous DeliveryBug fixes
> Some of the notable bug fixes in GitLab 13.7 are:
>
> - [Vulnerability identifier shows as link even though it doesn't have a link](https://gitlab.com/gitlab-org/gitlab/-/issues/288755)
> - [In the Vulnerability Report, the project picker doesn't show all projects in a group](https://gitlab.com/gitlab-org/gitlab/-/issues/268241)
> - [Group Security Dashboard shows incorrect vulnerability counts](https://gitlab.com/gitlab-org/gitlab/-/issues/244380)
> - [npm package API rate limit causes failed pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/244880)
> - [NuGet package API rate limit causes failed pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/246538)
> - [Recent issues/epics/MR autocomplete suggestions don't show items with exactly the same title](https://gitlab.com/gitlab-org/gitlab/-/issues/276758)
> - [Global search doesn't find a result when project search does](https://gitlab.com/gitlab-org/gitlab/-/issues/277390)
> - [Global search matching terms are difficult to read in dark mode](https://gitlab.com/gitlab-org/gitlab/-/issues/281023)
> - [It's not possible to list container repository registries and images on Geo secondary](https://gitlab.com/gitlab-org/gitlab/-/issues/285475)
> - [`replicate-geo-database` fails on fresh secondary installs](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5618)
> - [When selecting issue type and closing the dropdown the issue gets submitted right away](https://gitlab.com/gitlab-org/gitlab/-/issues/273580)
> - [A warning incorrectly appears when there are less than 1000 epics on a roadmap](https://gitlab.com/gitlab-org/gitlab/-/issues/271401)
> - [After clicking "Edit" in the swimlanes sidebar for labels, the dropdown doesn't open until you click the dropdown](https://gitlab.com/gitlab-org/gitlab/-/issues/276797)
> - [Expired iterations don't appear in the sidebar](https://gitlab.com/gitlab-org/gitlab/-/issues/287868)
[Add support for Kubernetes versions 1.17, 1.18, 1.19](https://docs.gitlab.com/ee/user/project/clusters/#supported-cluster-versions):
> GitLab support for more recent Kubernetes versions enables you to benefit from GitLab's Kubernetes integrations, such as the GitLab Agent for Kubernetes, Auto DevOps, and - on more recent clusters - GitLab Managed Apps. GitLab has added official support for Kubernetes versions [1.17, 1.18, and 1.19](https://docs.gitlab.com/ee/user/project/clusters/#supported-cluster-versions).
Kubernetes Management[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> GitLab instances deployed via the Helm Chart will experience a brief outage during this upgrade [due to a change to the way Webservice deployments are managed](#upgrade).
>
> - Traffic can now be [split by path across different deployments](https://docs.gitlab.com/charts/charts/gitlab/webservice/#deployments-settings) of the GitLab Webservice chart, allowing for division of workloads
> - `nginx` has been updated to `v0.41.2`, a significant update. Due to Pod parameter changes upstream, a brief outage might occur as the underlying pods restart.
> - `registry` has been updated to 2.12.0-gitlab, `gitlab-kas` to 13.7.0, `gitlab-runner` chart to 0.23.0, `gitlab-exporter` to 7.1.2
> - The termination grace period for NGINX is [now configurable](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/nginx/index.md#configuration) using `terminationGracePeriodSeconds`
> - GitLab Praefect now supports [TLS encryption](https://docs.gitlab.com/charts/charts/gitlab/praefect/#running-praefect-over-tls)
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - ARM64 packages are [now available](https://about.gitlab.com/install/#centos-8) for CentOS 8, thanks [HiKey](https://gitlab.com/HiKey)!
> - LDAP credentials can [now be encrypted](#support-for-encrypted-ldap-credentials-in-omnibus-gitLab).
> - Pages now supports [HTTPS over PROXYv2 protocol](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4760).
> - `registry` has been updated to 2.12.0-gitlab, `consul` to 1.6.6, `grafana` to 7.3.3, `prometheus` to 2.22.2, and `libjpeg-turbo` to 2.0.6.
> - GitLab 13.7 includes [Mattermost 5.29](https://mattermost.com/blog/mattermost-release-v5-29/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes the general availability of Mattermost Omnibus, plus much more. This version also includes [security updates](http://about.mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
Omnibus Package[Support for encrypted LDAP credentials](https://docs.gitlab.com/ee/administration/auth/ldap/index.html#using-encrypted-credentials) (self-managed only):
> GitLab uses a unified configuration file, for example `gitlab.rb` in Omnibus GitLab, which makes
> configuration easy across all of the bundled services. Included in this configuration file are some secrets, like the
> credentials to authenticate to the LDAP server. While access to this file does require elevated privileges, best practice
> is to separate secrets from configuration.
>
> Omnibus GitLab and Source installs now support [encrypted credentials](https://docs.gitlab.com/ee/administration/encrypted_configuration.html), with the first credential supported being LDAP. This reduces the sensitivity of the GitLab configuration file, and also helps to achieve customer compliance requirements.
Omnibus Package[PostgreSQL 12 is the default for new installs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later) (self-managed only):
> Starting with [GitLab 13.3](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#postgresql-12-is-now-available), PostgreSQL 12 has been available as an opt-in option for both Omnibus packages as well as our Helm chart. PostgreSQL 12 offers [significant indexing and partitioning benefits](https://www.postgresql.org/about/news/postgresql-12-released-1976/), along with broader performance improvements.
>
> In GitLab 13.7, new installations of GitLab will default to PostgreSQL 12 starting with 13.7. To manually upgrade, run [`gitlab-ctl pg-upgrade`](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
>
> Multi-node database instances will need to switch from [repmgr to Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni), prior to [upgrading with Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#upgrading-postgresql-major-version-in-a-patroni-cluster). Geo secondaries can then be [updated](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance) and re-synchronized.
Omnibus Package, Cloud Native Installation[Improved UI for project creation](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-project):
> The improved user interface for adding a project makes it easier to select between creating a blank project, starting a project from a template, importing an existing project, and creating a CI/CD-only project for external repositories.
Importers[Improved group members list filtering and sorting](https://docs.gitlab.com/ee/user/group/#filter-and-sort-members-in-a-group):
> We are continuing to improve our group members list with a new filtering and sorting experience. This will allow group administrators to quickly find the member information they need. For example, sorting by "Last sign-in" can be used to find users who haven't accessed GitLab recently and assist in license management activities.
Subgroups[Database queries are faster when using a load balancer](https://docs.gitlab.com/ee/administration/database_load_balancing.html):
> Many database queries are repeated several times and can be cached to improve overall performance. For GitLab, [roughly 10% of all queries](https://gitlab.com/gitlab-org/gitlab/-/issues/276188#note_463032681) can be cached. In GitLab 13.7 we enabled database query caching when [database load balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html) is used, leading to significant overall performance improvements. On GitLab.com this translates to caching ~700,000 queries every minute and improving the overall request time by up to 10%.
>
> For requests that executed more than 100 queries, we improved request duration [between 11-31% and cached ~30% of all SELECT statements](https://gitlab.com/gitlab-org/gitlab/-/issues/276188#note_463401368) that would be executed on the database replica otherwise.
MemoryPerformance improvements
> In every release, we continue to make great strides improving GitLab's performance. We're committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
>
> In GitLab 13.7, we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.7 are:
>
> - [Vulnerability reports load quicker](https://gitlab.com/gitlab-org/gitlab/-/issues/284953)
> - [Vulnerability state and severity counts load quicker](https://gitlab.com/gitlab-org/gitlab/-/issues/227765)
> - [Test report job page is faster and more responsive](https://gitlab.com/gitlab-org/gitlab/-/issues/280512)
> - [Active users count license query was improved](https://gitlab.com/gitlab-org/gitlab/-/issues/11752)
> - [Speed up MR Diffs by gradually loading larger batches](https://gitlab.com/gitlab-org/gitlab/-/issues/224161)
[See which commits and pipelines run in the fork project vs. the parent project](https://docs.gitlab.com/ee/ci/merge_request_pipelines/#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project):
> After we implemented [issue #217451](https://gitlab.com/gitlab-org/gitlab/-/issues/217451) in GitLab 13.3, you gained the ability to allow a parent project's developers to create pipelines for merge requests in forked projects. However, there was no way to know the context in which the pipeline ran.
>
> In this release, you can now see which commits and pipelines ran in the forked project vs. the parent project. Forked commits have a unique badge and a tooltip that lets you know they ran from a forked merge request. This makes it simple to understand the context in which your pipeline ran and eliminates the need to investigate the origin in more detail.
Continuous Delivery[Define your release description in an external file](https://docs.gitlab.com/ee/ci/yaml/#releasedescription):
> If you [create releases in your pipelines via your project's `.gitlab-ci.yml` file](https://docs.gitlab.com/ee/user/project/releases/index.html#release-cli-command-line), you've probably found it difficult to maintain each release's description. In GitLab 13.7, you can now define your release description in a source-controlled or auto-generated file and call it from `.gitlab-ci.yml`. Doing so loads the file's content into your release description as Markdown. This makes releases easier for you to create, maintain, and use with version control and is especially useful if you want to auto-generate your changelogs. Huge thanks to [Nejc Habjan](https://gitlab.com/nejch1) and Siemens for a great community contribution!
Release Orchestration[Clone an issue with a quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html):
> To make generating similar issues more efficient, issues now support a `/clone` quick action, which creates a new issue in the same project, with an identical title, description, and metadata. The `/clone` quick action replaces a more cumbersome process, which involves multiple steps to create an issue, copy the ID or path of the source issue, and use the `copy_meta` quick action.
>
> By default, issues are cloned into the same project and do not include system notes and comments, but you can also change the default behavior when cloning.
Issue Tracking[Use a custom email address with Service Desk](https://docs.gitlab.com/ee/user/project/service_desk.html#using-custom-email-address):
> The email address for the GitLab Service Desk has been difficult
> to remember, and therefore difficult for your users to use. With the
> introduction of configurable email address, it's now possible to choose an
> address suffix that makes sense for your business identity, and is easier for your
> users to remember. This is one more step GitLab is taking to enable you to
> provide top quality support to your users.
Service Desk[Reviewers for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/):
> Asking a colleague to review your code should be a routine part of contributing code, but it's often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.
>
> GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone. The new "Reviewers" field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request. This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.
>
> Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center. You can follow along in the [merge request reviewer assignment epic](https://gitlab.com/groups/gitlab-org/-/epics/1823) for more details.
Code Review[Choose to show one file at a time directly from merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation):
> Merge request reviews are an essential task to ensure quality code from contributors, as this is where most of the communication between author and reviewer takes place. However, as merge requests become larger and more files are involved, navigation and performance of merge request diffs can become difficult.
>
> GitLab 13.7 introduces the option to show one file at a time in the merge request view. As you navigate to the **Changes** tab of the merge request, click the gear icon and check the box labeled **Show one file at a time**. This will display a single file at a time and enable the **Prev** and **Next** buttons to navigate among files.
>
> Single file mode provides a cleaner workspace and enhances the reviewer focus on a single file, while improving the performance and navigation of the merge request diff.
Code Review[View Merge Request changes in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#sidebar-details):
> When working in VS Code to review a merge request, easily referencing changes often requires checking out a branch and then trying to determine the diff between that branch and the merge target.
>
> With the [3.7.0 Release](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#370-2020-12-08) of [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow), merge request changes are available directly in VS Code. This provides quick access to seeing changes for merge requests in your projects.
>
> As we continue working on bringing a complete [Code Review experience to VS Code](https://gitlab.com/groups/gitlab-org/-/epics/4607), we'll be bringing [comments on diffs](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/266) to the extension next.
Editor Extension[Distinguish between formatting changes and edits made from the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#how-it-works):
> The Static Site Editor offers an intuitive and familiar WYSIWYG editing mode for Markdown content. To ensure consistently formatted Markdown output, the WYSIWYG editor automatically reformats the page content to match the styling conventions defined in the Markdown parser. This happens entirely in the background before you even start editing. These formatting changes, however, are committed at the same time as your content edits. If the page you are editing did not follow the same styling conventions, it can be difficult for reviewers of the resulting merge request to differentiate between your intentional changes and the automatic formatting.
>
> Starting in GitLab 13.7, the Static Site Editor will automatically fix inconsistencies in the Markdown syntax and commit any necessary formatting changes to a new branch. Once you're done editing, the Publish button creates a separate commit that contains only your changes. This can save time for your reviewers, who instead of having to sift through syntax changes, can focus on your content.
>
> In the future, we plan to make the formatting preferences customizable and you can [follow the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/244483) for updates.
Static Site Editor[GitLab Runner for Red Hat OpenShift](https://docs.gitlab.com/runner/install/openshift.html):
> Available today is the GitLab Runner container image for the [Red Hat OpenShift Container Platform](https://www.openshift.com/products/container-platform). To install the runner on OpenShift, you can use the new [GitLab Runner Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator) available from the beta channel in Red Hat's Operator Hub - a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. Operator Hub is deployed by default in the OpenShift Container Platform. We plan to transition the GitLab Runner Operator to the stable channel, and by extension [GA](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/6), in early 2021. Finally, we are also developing an operator for GitLab, so stay tuned to future release posts for those announcements.
GitLab Runner[Improved artifact downloads with child pipelines](https://docs.gitlab.com/ee/ci/yaml/#needspipelinejob):
> Previously, downloading artifacts from a parent pipeline to a child pipeline did not always give the artifacts desired. If two parent pipelines ran around the same time, the child pipeline could download the artifacts from the newer pipeline unexpectedly.
>
> Now you can use the new `needs:pipeline` syntax to tell the child pipeline the exact pipeline to download artifacts from. You can use it to download artifacts from the parent pipeline, or a different child pipeline in the same parent-child pipeline hierarchy.
Continuous Integration (CI)[Pre-filled variables when running pipelines manually](https://docs.gitlab.com/ee/ci/pipelines/#run-a-pipeline-manually):
> Previously when you wanted to manually run a pipeline, you needed to know the relevant variables and then enter them on the "Run Pipeline" page. This can be tedious and error-prone if there are numerous key-value pairs to enter. Now, the Run Pipeline form will generate with pre-filled variables for your pipeline based on the variable definitions in your `.gitlab-ci.yml` file, making this process more efficient.
Continuous Integration (CI)[GitLab Runner 13.7](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.7 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
>
> #### What's new:
>
> - [Ability to remove `umask 0000` for jobs executed with the GitLab Runner Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1736)
> - [Support extra hosts for Kubernetes with host aliases](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2818)
> - [Support Kubernetes Pod DNS configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6562)
> - [Improve cache upload speed on high-speed networks](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25801)
> - [Add support for Windows Server, version 2004 (Semi-Annual Channel Release)](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26420)
> - [Remove dependency from Docker Hub for Kubernetes init containers](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27098)
> - [Publish GitLab Runner Docker images to Amazon Elastic Container Registry](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27269)
> - [Pull helper image from GitLab.com Container Registry instead of Docker Hub, behind `FF_GITLAB_REGISTRY_HELPER_IMAGE` feature flag](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27196)
> - [Require TLS 1.2 as a minimum version](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2576)
> - [Allow specifying `basefolder` when creating VirtualBox VM](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2461)
>
>
> #### Bug Fixes:
>
> - [Remove duplicate logs when GitLab Runner is used with systemd](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3351)
> - [Error cleaning up secrets: resource name might not be empty](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26996)
> - [FastZip archives have warnings when files extracted by default archiver](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27285)
> - [Remove .git/config.lock in build directory](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2580)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-7-stable/CHANGELOG.md).
GitLab Runner[Avoid Docker rate limits and speed up your pipelines](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#docker-hub-rate-limits-and-the-dependency-proxy):
> For faster and more reliable builds, you can use the Dependency Proxy to cache the container images hosted on Docker Hub. But, when Docker started to enforce [rate limits on pull requests from Docker Hub](/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/), you noticed that even when your image was pulled from the cache, Docker counted it against your limit. That's because the Dependency Proxy was only caching the image's layers (or blobs) and not the manifest, which contains information about how to build a given image. Since the manifest is required, a pull request was still required. This also means that if Docker Hub was unavailable, you couldn't pull your image.
>
> Moving forward, the Dependency Proxy will cache both the image's layers and manifest. So, the first time you pull `alpine:latest`, the image will be added to the Dependency Proxy cache and count as one pull against your rate limit. The next time you pull `alpine:latest`, it will be pulled from the cache, even if Docker Hub is unavailable and will not count against your rate limit.
>
> Don't forget, as of milestone 13.6, the [Dependency Proxy is available in Core](/releases/2020/11/22/gitlab-13-6-released/#the-dependency-proxy-is-now-open-source). So, give it a try and let us know what you think. Or better yet, consider contributing to one of the open [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Apackage&label_name[]=Category%3ADependency%20Proxy).
Dependency Proxy[Use pre-defined variables with the Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-within-cicd):
> By proxying and caching container images from Docker Hub, the Dependency Proxy helps you to improve the performance of your pipelines. Even though the proxy is intended to be heavily used with CI/CD, to use the feature, you had to define your own variables or hard-code values in your `gitlab.ci-yml` file. This made it difficult to get started for individuals, and prevented it from being a scalable solution, especially for organizations with many different groups and projects.
>
> Moving forward, you can use [pre-defined environment variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) as an intuitive way to use the Dependency Proxy. The following variables are supported:
>
> - `CI_DEPENDENCY_PROXY_USER`: a CI user for logging in to the Dependency Proxy.
> - `CI_DEPENDENCY_PROXY_PASSWORD`: a CI password for logging in to the Dependency Proxy.
> - `CI_DEPENDENCY_PROXY_SERVER`: the server for logging in to the Dependency Proxy.
> - `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`: the image prefix for pulling images through the Dependency Proxy.
>
> Give it a try and let us know what you think!
Dependency Proxy[Packages built with CI/CD always display build info](https://docs.gitlab.com/ee/user/packages/package_registry/#use-gitlab-cicd-to-build-packages):
> If you've been publishing packages to the Package Registry, you might have noticed that packages built with GitLab CI/CD did not always display the commit and pipeline responsible for creating or updating your package. This might occur for a few reasons.
>
> First, it's possible that we didn't support this functionality yet, as was the case with [Composer](https://gitlab.com/gitlab-org/gitlab/-/issues/254385) and [Conan](https://gitlab.com/gitlab-org/gitlab/-/issues/234002). Second, an issue occurred for those of you who have been updating the same version of a package from different branches or commits. A package with the same version can be published from different branches and/or commits. However, until recently, the UI displayed only the first deployment and left out any updates. In addition, the details page displayed the branch that created the package, not the most recent commit. As a result, you had to try and find this information by viewing your commit history, which was not very efficient.
>
> Moving forward, any package created or updated with GitLab CI/CD will display commit and pipeline info in the Packages user interface. To avoid performance or UX issues, only five updates of a package will be displayed. In milestone 13.8, we will create a [design that helps you intuitively view all historical data](https://gitlab.com/gitlab-org/gitlab/-/issues/292215). In the meantime, you can use the [Packages API](https://docs.gitlab.com/ee/api/packages.html#get-a-project-package) to view the entire build history of a given package.
Package Registry[Quickly find and view generic packages](https://docs.gitlab.com/ee/user/packages/package_registry/#view-packages):
> You can easily publish generic files, such as release binaries, using the GitLab Package Registry. However, if you use the Packages UI and another package manager format, you might have noticed you couldn't select a tab to quickly view only your generic packages.
>
> We recently added a tab to the Packages UI called **Generic** so you can limit your view to only your generic packages. We hope this helps you find and validate your packages faster and more efficiently.
Package Registry[Use the Dependency Proxy with private projects](https://docs.gitlab.com/ee/user/packages/dependency_proxy/index.html#authenticate-with-the-dependency-proxy):
> You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub. Until recently the feature was only available for public groups, preventing many of you from being able to use it.
>
> You can now use the Dependency Proxy with private projects. You can reduce your reliance on Docker Hub by caching your container images for future use. Because the Dependency Proxy is storing Docker images in a space associated with your group, you must authenticate with your GitLab username and password, or with your personal access token with the scope set to at least `read_registry`.
Dependency Proxy[Improved multi-project support for SAST analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#multi-project-support):
> GitLab [security scans](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools) automatically detect code language and run appropriate analyzers. With monorepos, microservices, and multi-project repositories, more than one project can exist in a single GitLab repository. Previously our security tools could only detect single projects in repositories. With this release, our SAST analyzers can [now intelligently detect multi-project repositories and run appropriate scanners](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) for each project and report vulnerabilities. This will make it easier and more streamlined for users with multi-project repos to leverage our security tools. [Future updates](https://gitlab.com/gitlab-org/gitlab/-/issues/219937) will further improve the dashboard and reporting functionality for these types of projects.
SAST[Improved MR experience for security scans](https://docs.gitlab.com/ee/user/application_security/#viewing-security-scan-information-in-merge-requests):
> With [SAST and Secret Detection now available to all usage tiers](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#sast-security-analyzers-available-for-all), we have improved the experience for all GitLab users [interacting with Secure scan results](https://docs.gitlab.com/ee/user/application_security/#interacting-with-the-vulnerabilities) in a merge request, making it easier for anyone to access [Secure scanning findings](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools). Security scan results previously were only accessible on the [Pipeline Overview page](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts) and you had to know where to look to find them. Now all merge requests will show if there have been security scans run and help you find the job artifacts. This change does not [modify the MR experience for Ultimate users](https://docs.gitlab.com/ee/user/application_security/sast/#summary-of-features-per-tier).
SAST, Secret Detection