GitLab.org/GitLab: Release v13.8.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.8
Released: 2021-01-22
License: MIT
Release Assets:
[Allow GitLab.com group owners to bypass SSO enforcement](https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement) (SaaS only):
> In GitLab 13.8, we will allow group owners to bypass SSO enforcement to access to their owned top-level groups. This will allow group owners to modify SAML SSO settings and prevent group member lockout due to SAML SSO misconfiguration or changes in identity providers.
Authentication and Authorization[Welcome email for SAML and SCIM provisioned accounts](https://docs.gitlab.com/ee/user/profile/notifications.html#notification-events) (SaaS only):
> In GitLab 13.8, users created via SCIM or SAML will receive a welcome email that informs them that their account was created for use within their organization's group. Future iterations will give group administrators more control over accounts that are provisioned by their SAML or SCIM integrations.
Subgroups[Deployment frequency charts](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts):
> Knowing and monitoring deployment frequency is a starting point for organizations adopting DevOps. We are proud to introduce deployment frequency charts at the project level so that you and your development teams can monitor the efficiency of deployments over time, find bottlenecks, and make improvements when necessary. This is the first of the [DORA metrics](https://gitlab.com/groups/gitlab-org/-/epics/4358) that we are making available within GitLab out of the box.
Continuous Delivery[Export requirements to a CSV file](https://docs.gitlab.com/ee/user/project/requirements/#export-requirements-to-a-csv-file):
> After completing development and verifying your product meets all requirements, it may be necessary to export the requirement status to allow for incorporation into a higher level requirements traceability analysis. With the introduction of the requirements export feature, this is now possible! Simply initiate the requirement export and they will be automatically sent to you in .CSV format, ready to import into other tools or provide to your customer.
>
> This is the first iteration of this feature, so please provide feedback and follow along in the [Requirements Export Epic](https://gitlab.com/groups/gitlab-org/-/epics/4672).
Requirements Management[API Fuzz Testing results now visible in Security Dashboard](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/#interacting-with-the-vulnerabilities):
> API fuzz testing results are now shown in the Security Dashboard and
> all other locations that security scanners show their results. You
> can now triage API fuzz testing results, create issues for them, and
> engage with your teams just like you can with other scanners.
>
> We're incredibly excited to bring these results out of the **Tests**
> tab so that you can integrate API fuzz testing alongside other
> security scanners and truly shift security left.
Fuzz Testing[Add DAST.latest.gitlab-ci.yml template](https://docs.gitlab.com/ee/user/application_security/dast/#latest-template):
> GitLab's DAST has always had only a single template that isn't versioned and is updated whenever we need to change things. This has proven difficult for users whose tests break after a template update. Starting in GitLab 13.8, we introduce a `.latest` version of the template. This template includes all template changes made between major releases, including breaking changes. This gives users a warning that changes are coming and enables them to test the changes for themselves before being forced to switch.
>
> Breaking changes are brought into the stable template on the next major GitLab version. For non-breaking changes, these can be brought into the stable template after living in the latest template for a few releases. The speed at which the changes are incorporated into the stable template depends on a number of factors and takes into account feedback from users as they test the changes in the latest template.
DAST[Active scan mode in on-demand DAST scanner profile](https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scan-modes):
> Used in conjunction with the new site validation feature, active DAST scans are now available for configuration in the on-demand DAST scanner profile. After validating a site for ownership, you can configure an active scan to run against the site. These scans include actual, destructive, malicious attacks against the site. Because of this, we recommend and encourage that you only use an active scan on staging and test sites that do not contain production data, where data loss is not a concern.
DAST[Site validation for on-demand scans](https://docs.gitlab.com/ee/user/application_security/dast/#site-profile-validation):
> Beginning in GitLab 13.8, users can validate that they own or have permission to test the domains added as a site profile. By adding a text file with a project- and site-specific string to their site, users can validate ownership of the domains. The validation process unlocks the ability to run active DAST scans against the domain. Since active DAST scans include actual attacks against the site, site validation provides a level of assurance that users can't accidentally run an active scan against a site where they could cause data loss or damage. Because of this, any site profile that uses a domain that isn't validated is only allowed to use scanner profiles that use a passive scanning mode.
DAST[Faster issue searching in Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> Advanced Search can scale from small personal instances all the way up to GitLab.com. On some of the largest instances, however, search can slow down as the size of the index grows, and the number of permissions needing to be checked.
>
> In GitLab 13.8 we have split out issues into their own index, making Advanced Search faster for larger instances. We have also simplified the method of permissions checks, further improving performance.
>
> This update will apply automatically, without a need to conduct a manual reindex. The process takes less than 2 hours, however, there will be a delay in indexing new content while this completes.
Global Search[Improved file searching in Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html#syntax-search-filters):
> Searching for a file is the top use case in Advanced Search. Before this release, searching for files often required some specific syntax and was not very intuitive.
>
> With GitLab 13.8, Advanced Search now supports full path searching. We have also made the [file syntax](https://docs.gitlab.com/ee/user/search/advanced_search.html#syntax-search-filters) search more flexible.
Global Search[Geo support for PostgreSQL high-availability in Alpha](https://docs.gitlab.com/ee/administration/geo/setup/database.html#patroni-support) (self-managed only):
> [Patroni](https://github.com/zalando/patroni) is a solution for
> PostgreSQL high availability which also allows the
> configuration of a highly available PostgreSQL standby cluster on a Geo
> secondary. This configuration is important when a secondary is used as
> part of a disaster recovery strategy because it allows systems
> administrators to mirror the number of database nodes on the primary and
> secondary. This means that after a failover, no additional database nodes need to be provisioned to regain high-availability.
>
> Geo now provides [alpha-level](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha) support for highly available PostgreSQL configurations using [Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#patroni). We've upgraded [Patroni to 2.0.1](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5870), added [failover documentation](https://gitlab.com/gitlab-org/gitlab/-/issues/276471), and fixed a number of bugs.
Disaster Recovery[Group webhook for members (edit, remove)](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#group-member-events):
> In GitLab 13.7, we introduced a [webhook](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#group-webhooks-for-members-mvc) that is triggered when a new member is added to a group. In GitLab 13.8, the group member events webhook will also be triggered if the access level of a user has changed, the expiration date for user access has been updated, or a user has been removed from the group. With the addition of these events, the group member events webhook can be used to be aware of all changes made to group members without relying on API calls which put unnecessary performance load on your GitLab instance.
Subgroups[Scope a board to the current iteration](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards):
> Many teams use boards to manage issues during an iteration. In 13.6, we added support for [filtering issues on a board to a specific Iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/118742), but it is cumbersome to remember to apply that filter every time you go to your board.
>
> In this release, we've added the ability to scope your board to the currently active iteration.
Boards[Group issues by label in the iteration report](https://docs.gitlab.com/ee/user/group/iterations/#group-issues-by-label):
> You can now group issues in an iteration report by labels. This provides teams with a way to view progress during an iteration segmented by the many dimensions that labels are often used to represent.
Issue Tracking[Distributed Reads for Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#distributed-reads) (self-managed only):
> Users want the highest possible levels of fault tolerance in highly-available Gitaly Clusters. This release introduces distributed reads for Gitaly Clusters. Instead of always reading from the primary node, Gitaly now automatically distributes read requests to any up-to-date node in the cluster. Distributing requests maximizes both performance and value proposition by giving your users access to all the computing resources provisioned in the cluster.
> Users also want to prevent performance degradation from noisy-neighbor repositories on the same node. This issue is particularly important for large and busy monorepos, where thousands of engineers and CI pipelines simultaneously access the same Git repository. By horizontally distributing read requests, Gitaly Clusters improve performance across all repositories in the cluster.
> To read more about Gitaly Clusters and how we've developed our own traffic management solution for Gitaly Cluster, see our blog post, [Meet Praefect: The traffic manager making your Git data highly available](/blog/2021/01/21/high-availability-git-storage-with-praefect/).
Gitaly[Approval Rule information for Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html):
> When working to have your merge request reviewed, approved, and finally merged, it's important to select the right people to perform those tasks. Asking for a review from people who can't provide the approvals can slow down the process of delivering your contribution.
>
> From GitLab 13.8 onwards, when selecting a reviewer for your merge request, you can see which approval rules that the user matches displayed right below the reviewer's name.
Code Review[Optional sections for code owners](https://docs.gitlab.com/ee/user/project/codeowners/#optional-code-owners-sections)):
> [Code owner sections](https://docs.gitlab.com/ee/user/project/codeowners/#code-owners-sections) allow multiple teams to configure their own code owners independently in the same file. This helps when multiple teams are responsible for common parts of the code, by helping authors getting feedback from the right reviewers. However, when approval from Code Owners is required, this applies to all the sections meaning all teams need to approve, which can hold back changes from getting merged.
>
> GitLab 13.8 introduces the ability to designate optional sections in your `CODEOWNERS` file. Simply prepend the section name with the caret `^` character and the section will be treated as optional. This means, related changes through merge requests will not require approval from designated owners. With optional sections, you may continue to designate responsible parties for various parts of the code while providing a more relaxed policy for parts of your project that may be updated often but don't require stringent reviews.
Source Code Management[Upload metrics images directly to incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#metrics):
> Processing incidents during a fire-fight requires responders to coordinate across multiple tools to evaluate different data sources. Collecting and assessing metrics, logs, and traces - and sharing these with a response team - is time-consuming and challenging. We've streamlined this workflow by providing drag-and-drop uploads for these screenshots in a new **Metrics** tab on incidents. Aggregate and centrally locate all your screenshots of metrics so your team can quickly access and reference important charts.
Incident Management[Download artifacts directly from the merge request widget](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts):
> In this release, we added the ability to download build artifacts directly from the MR widget. This is especially useful for mobile development. An example of this is where users want to test an Android package of a specific build created on a physical device or an emulator. You can now access these artifacts directly from the merge request widget without having to find the artifacts buried in the pipeline view.
Continuous Delivery[Deploy Boards are available in Core](https://docs.gitlab.com/ee/user/project/deploy_boards.html):
> Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.
>
> Earlier this year GitLab committed to [moving 18 features](/blog/2020/03/30/new-features-to-core/) to our open source core product. With this release of GitLab we've completed the work to move Deploy Boards to Core. We're excited about bringing these features to more users and seeing what use cases and workflows you're able to use them for.
Advanced Deployments[GitLab Pages is now available for Kubernetes deployments of GitLab](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html) (self-managed only):
> GitLab Pages is a popular static-site hosting service built into GitLab, and we are excited to announce that it is now available for GitLab instances running on Kubernetes. Pages was one of the [last remaining feature gaps](https://docs.gitlab.com/charts/#limitations) compared to an Omnibus deployment.
>
> Custom domains [are supported](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html#general-settings) today, however, access control will [arrive in a future release](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2443).
Cloud Native InstallationBug fixes
> Some of the notable bug fixes in GitLab 13.8 are:
>
> - [Container Scanning no longer reported the analyzer version](https://gitlab.com/gitlab-org/gitlab/-/issues/276886).
> - [Long titles were misaligned on the Pipeline Security tab in vulnerability reports](https://gitlab.com/gitlab-org/gitlab/-/issues/294410).
> - [Inline code coverage was not loading with self-closing source tag in cobertura report](https://gitlab.com/gitlab-org/gitlab/-/issues/296141).
> - [Grouping/swimlanes choice should persist after board has been edited](https://gitlab.com/gitlab-org/gitlab/-/issues/282299).
> - [LFS issue when using GitLab Geo and location-aware Git URL](https://gitlab.com/gitlab-org/gitlab/-/issues/294483).
> - [Fixed pipeline intermittent lint failures](https://gitlab.com/gitlab-org/gitlab/-/issues/23531).
[Manage Terraform state files through the UI](https://docs.gitlab.com/ee/user/infrastructure/terraform_state.html#managing-state-files):
> When managing your infrastructure with Terraform, you might create multiple state files, such as state files for each branch. To debug issues, you need an overview of the state files attached to your project, and various actions you can take for each state file. In previous versions of GitLab, managing Terraform state files required the API for tasks like releasing a state lock. We are now introducing a UI to list existing state files. It enables project maintainers to lock or unlock a state file, remove the state JSON, or to remove a state file entirely.
Infrastructure as Code[GitLab Terraform Provider 3.4 updates](https://docs.gitlab.com/ee/user/infrastructure/#the-gitlab-terraform-provider):
> If you use Terraform to set up GitLab, we are happy to announce version 3.4.0 of [the GitLab Terraform Provider](https://github.com/gitlabhq/terraform-provider-gitlab/releases). In the past months, the provider received support of project mirroring, group sharing, project approval rules, and instance-level CI variables, besides many smaller enhancements and a few bug fixes.
Infrastructure as Code[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> In [GitLab 13.8](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/1793), we added the ability to specify multiple virtual storages within our Praefect chart. If you have [enabled Praefect](https://docs.gitlab.com/charts/charts/gitlab/praefect/), which is off by default and not yet GA, please note that the StatefulSet name for Gitaly will now include the virtual storage name. Because of this name change, any existing Praefect-managed Gitaly StatefulSet names (and, therefore, their associated PersistentVolumeClaims) will change as well, leading to repository data appearing to be lost. In this case, repository data can be restored by following the [managing persistent volumes documentation](https://docs.gitlab.com/charts/advanced/persistent-volumes/), which provides guidance on reconnecting existing PersistentVolumeClaims to previous PersistentVolumes.
>
> - GitLab Pages is [now available for Kubernetes deployments](#gitlab-pages-is-now-available-for-kubernetes-deployments-of-gitlab)
> - Praefect now supports [multiple virtual storages](https://docs.gitlab.com/charts/charts/gitlab/praefect/#multiple-virtual-storages).
> - The `registry` version has been updated to 2.13.1-gitlab
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - Process related metrics have been [removed from `gitlab-exporter`](https://docs.gitlab.com/omnibus/update/gitlab_13_changes.html#removal-of-process-metrics-from-gitlab-exporter). GitLab now exports these directly.
> - A [`patroni_role` has been added](https://docs.gitlab.com/omnibus/roles/#postgresql-roles) to easily configure Patroni nodes for scaled GitLab deployments.
> - Added [fallback to `postgresql[X]` settings](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4857) for more Patroni settings.
> - The `registry` component has been updated to `2.13.1-gitlab`, and `grafana` to 7.3.6, `patroni` to 2.0.1
> - The path where encrypted credentials are stored is [now configurable](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4884).
> - GitLab 13.8 includes [Mattermost 5.30](https://mattermost.com/blog/mattermost-release-v5-30/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes improvements to the Matterpoll plugin, deprecation of PostgreSQL v9.x, and more.
Omnibus Package[Single-node instances will now upgrade to PostgreSQL 12 by default](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later) (self-managed only):
> In GitLab 14.0, we plan to require [PostgreSQL 12](#postgresql-11-support). PostgreSQL 12 offers [significant indexing and partitioning benefits](https://www.postgresql.org/about/news/postgresql-12-released-1976/), along with broader performance improvements.
>
> To prepare, single-node instances using the Omnibus-packaged version of Postgres will now automatically upgrade to version 12 by default. If you prefer, you can [opt-out of automatic upgrades](https://docs.gitlab.com/omnibus/settings/database.html#opt-out-of-automatic-postgresql-upgrades).
>
> Multi-node instances, and any Geo secondaries, 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[Compare repositories and validate if they are the same](https://docs.gitlab.com/ee/administration/raketasks/check.html#checksum-of-repository-refs) (self-managed only):
> One Git repository can be compared to another by checksumming all refs of each repository. If both repositories have the same refs, and if both repositories pass an integrity check, then we can be confident that both repositories are the same. For example, this can be used to compare a backup of a repository against the source repository.
>
> The new `gitlab:git:checksum_projects` rake task allows systems administrators to select a subset of projects by ID or loop through all projects, and output a checksum of the Git references that can be compared to a copy of the same project.
Disaster Recovery[Migrate Groups directly between instances](https://docs.gitlab.com/ee/user/group/import/):
> A faster and easier way to migrate your GitLab Groups is on the way. Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files. In this release, we migrate only the Group object with basic fields. We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.
ImportersPerformance improvements
> In every release, we continue to make great strides in 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.8, we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.8 are:
>
> - [Reducing LCP in the Container Registry index page](https://gitlab.com/gitlab-org/gitlab/-/issues/280847).
> - [Using GraphQL for the vulnerability state dropdown](https://gitlab.com/gitlab-org/gitlab/-/issues/228740).
> - [Fixing `N+1` queries with loading group issues with GraphQL](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50328).
> - [Enabling `QueryCache` for `LoadBalancing`](https://gitlab.com/gitlab-org/gitlab/-/issues/276188#note_469296770).
> - [Swapping base `audit_events` table with a partitioned copy](https://gitlab.com/gitlab-org/gitlab/-/issues/241267).
[Improved pipeline status email subject line](https://docs.gitlab.com/ee/user/profile/notifications.html):
> GitLab sends email notifications when your pipeline succeeds, fails, or is fixed. In previous releases, these emails looked similar. This made it hard to tell the pipeline status without reading the entire body of the email. This release updates the subject line of these email notifications so you can determine pipeline status with a quick glance.
Continuous Delivery[Busy status indicator](https://docs.gitlab.com/ee/user/profile/#busy-status-indicator):
> With status updates, users can currently share a personalized status message and emoji with their team. We are now taking this one step further with a busy indicator. By marking yourself as Busy, your coworkers can easily see when you are unavailable for code reviews and other tasks. The Busy status will be displayed next to your name throughout the GitLab user interface.
Insights[Support for predefined variables in CI include section](https://docs.gitlab.com/ee/ci/yaml/includes.html#use-variables-with-include):
> Regulated customers rely on GitLab's CI/CD capabilities to define and automate their security and compliance jobs and processes for deploying changes to sensitive environments. They need to ensure they're maintaining separation of duties between the teams writing code and the teams deploying that code and these jobs always run in sensitive environments.
>
> In 13.8, you can now use [predefined project variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-environment-variables-reference) in the `include:` section of your `.gitlab-ci.yml` file. This change is part of a [bigger solution](https://gitlab.com/groups/gitlab-org/-/epics/3156) to bring better separation of duties control to your GitLab CI/CD pipelines.
Compliance Management[Send an email to an issue](https://docs.gitlab.com/ee/user/discussions/index.html#add-a-comment-to-an-issue-by-sending-email):
> To more efficiently integrate GitLab into your email workflows, each issue now has a unique email address. Emailing an issue creates a new comment on your behalf. You can now say goodbye to manually copying email content and attachments into your GitLab issues.
Issue Tracking[Display all available quick actions in autocomplete](https://docs.gitlab.com/ee/user/project/quick_actions.html):
> When you enter `/` into a description or comment field, all available [Quick Actions](https://gitlab.com/help/user/project/quick_actions) are now displayed in a scrollable list. Quick Actions are a great way to efficiently update data on an issue, merge request, or epic, and this small improvement helps them be more discoverable in the context in which they are used.
Issue Tracking[Click and drag multiline merge request comments](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#commenting-on-multiple-lines):
> Commenting on a single line is great for simple kinds of code review feedback, but often a comment addresses multiple lines in the diff. For instance, a portion of a logic block, a paragraph of prose, or an entire function. This forces users to choose a single line to provide feedback, but the feedback refers to other portions of the file.
>
> Previously, users could select multiple lines after posting a comment by adjusting line numbers up and down from the original comment point. Now, users can click at the beginning of a line and drag the comment marker across multiple lines to highlight and reference multiple lines when leaving feedback in a merge request.
Code Review[Rebase quick action for merge requests](https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics):
> [Rebase](https://docs.gitlab.com/ee/topics/git/git_rebase.html#regular-rebase) is a Git command used to reapply commits on top of a new commit. In practice, this means reapplying commits from a feature branch on top of the latest version of the target branch (e.g. `main`). In this way, it is possible to bring the feature branch up to date and resolve any conflicts without using a merge commit resulting in a simpler linear Git history.
>
> GitLab 13.8 brings the ability to execute the rebase [quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html) in merge requests, allowing you to quickly invoke the rebase Git utility.
>
> On a merge request comment, type `/rebase` and click the **Comment** button. It's that simple.
Source Code Management[Rate limit dry run mode and bypass mechanism](https://docs.gitlab.com/ee/administration/settings/user_and_ip_rate_limits.html):
> It can be challenging to set rate limits for your application in such a way to allow requests from trusted sources while blocking malicious traffic. We have made several enhancements to make it easier to properly set rate limits. First, you can now test rate limit settings using a [new dry run mode](https://docs.gitlab.com/ee/administration/settings/user_and_ip_rate_limits.html#try-out-throttling-settings-before-enforcing-them) that checks requests against each rate limit and logs the results without actually blocking the client. This lets you fine-tune request throttle settings before enabling them in production.
>
> Second, you can also [configure specific requests](https://docs.gitlab.com/ee/administration/settings/user_and_ip_rate_limits.html#use-an-http-header-to-bypass-rate-limiting). This allows you to better support trusted services.
>
> Finally, you can [configure specific users](https://docs.gitlab.com/ee/administration/settings/user_and_ip_rate_limits.html#allow-specific-users-to-bypass-authenticated-request-rate-limiting) to bypass the rate limiter. This allows you to better support trusted users accessing your GitLab instance.
API[Use rich output for Jupyter notebooks](https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/):
> Jupyter notebooks are documents that contain live code, equations, visualizations, and narrative text. They are widely used for data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and more. They are capable of using "rich output" to show an object's rendered representation, such as HTML, JPEG, SVG, or LaTeX files. Previously, opening the notebook in Jupyter was the only way to read it with rich output.
>
> GitLab 13.8 now shows rich output for Jupyter notebook content by default. This is an excellent way both to preview changes to your files as well as consume Jupyter notebook without ever having to leave GitLab.
Source Code Management[Link source merge requests for squash and merge commits](https://docs.gitlab.com/ee/user/project/merge_requests/versions.html#find-the-merge-request-that-introduced-a-change):
> When viewing a commit in GitLab, the merge requests containing the commit are linked. Finding the merge request that added the commit is very useful when you are trying to find the business and technical context of a change.
>
> If you use squash or merge commits, merge request information was not previously included. GitLab 13.8 now includes merge request links for all commit types, ensuring you can find where a change was introduced.
Source Code Management[Disable Operations features on a project](https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions):
> GitLab offers a variety of tools to help you monitor and operate your applications, but not all projects in GitLab are web applications. For example, if you are working on an NPM package, hosting configuration files, or using a Wiki-only project, you might find that the Operations features are not needed by your project.
>
> In GitLab 13.8, you can now disable the Operations features on a project-by-project basis, which removes access to the features and hides the menu item from the left sidebar. The new configuration can be found in **Settings > General** under the **Visibility, project features, permissions** section. Configuring your project in this way ensures that only the features that you use and that your project supports are available and visible in the GitLab interface.
Navigation & Settings[Quickly edit Wiki's sidebar](https://docs.gitlab.com/ee/user/project/wiki/#customizing-sidebar):
> Creating a Markdown file named `_sidebar` in the Wiki will use the contents of that file to generate a custom sidebar navigation menu for your project. Editing this file, however, was tricky as there was nowhere in the interface to open `_sidebar` again.
>
> Thanks to a wonderful community contribution from GitLab user [Frank Li](https://gitlab.com/lifrank1994), starting in GitLab 13.8 there is now an **Edit sidebar** button in the top right of the Wiki page. Clicking this button will automatically create the `_sidebar` file if it doesn't already exist and open it in the page editor. With this quick access, it is more intuitive to create and easier to maintain your custom Wiki navigation.
Wiki[Pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html):
> GitLab CI/CD provides you with flexible options to support a variety of advanced pipeline use cases. Pipeline syntax can be verbose and sometimes complicated, especially for those who are new to GitLab CI/CD. In this release, we are proud to introduce our first iteration of the Pipeline Editor.
>
> The editor makes the CI configuration authoring experience much easier for both novice and advanced users alike. The pipeline editor is a single solution that groups all the existing CI authoring features (and future ones) in a single location. The pipeline editor is the best place to go when configuring your pipeline.
>
> In addition to the editing experience, it has additional features that help you author pipelines without extra manual steps. [CI validation](#cicd-configuration-validation-in-pipeline-editor) continuously checks your pipeline configuration and provides you with an indicator that your pipeline configuration is valid. [The new Pipeline Visualizer](#visualization-of-pipeline-configuration) provides you with a graphic representation of your pipeline configuration. The [Lint tab](#ci-lint-tool-in-the-pipeline-editor-page) validates your pipeline syntax and provides you with details about each job.
Pipeline Authoring[CI lint tool in the pipeline editor page](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#lint-ci-configuration):
> The CI lint tool validates your pipeline syntax and provides you with some details about each job. Previously, CI lint was located on the jobs page which was difficult to find and access. In this release, accessing this tool is much easier than before because it is now included as a part of the new Pipeline Editor. With this improvement, you can easily use CI lint while editing your configuration and quickly validate that your syntax is what you want before committing the changes.
Pipeline Authoring[CI/CD configuration validation in Pipeline Editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#validate-ci-configuration):
> Previously, to validate your CI/CD configuration, you had to navigate to the CI lint page or commit your changes and look for any errors. In this release, we've added verification in the pipeline editor itself. It continuously checks your pipeline configuration before writing your `.gitlab-ci.yml` file and provides you with an indicator that your configuration is valid. This saves you time and effort that could otherwise be spent optimizing your pipeline.
Pipeline Authoring[Visualization of pipeline configuration](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#visualize-ci-configuration):
> A complex CI configuration can be difficult to understand as a developer, especially when trying to predict how your pipeline might behave (or misbehave). Without a visual aid, it is challenging to form a mental image of the relationships between all of the jobs and determine how they are interconnected. In our first iteration of a pipeline visualization, you can now see a graphic representation of your `.gitlab-ci.yml` configuration to better understand and predict how your pipelines will perform.
Pipeline Authoring[Repeat failed test counter](https://docs.gitlab.com/ee/ci/unit_test_reports.html#number-of-recent-failures):
> When you're reviewing the results of a Merge Request's pipeline execution, there may be test failures to investigate further. It's often hard to validate whether a test failure is accurate and needs to be fixed, or if it's simply a flaky test that can be ignored. Figuring this out can be even more difficult when you're not dealing with a brand new test failure.
>
> The first minimal viable change for the repeat failed test counter will provide you a count of how often a test has failed in previous pipelines on the Test Summary Merge Request Widget. We are requesting feedback from the wider community in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/242233) to understand what we can improve in future iterations of this feature.
Code Testing and Coverage[Configure multiple image pull policies for Docker executor](https://docs.gitlab.com/runner/executors/docker.html#set-multiple-pull-policies):
> When your CI jobs are retrieving a container image from a container registry, a lost network connection can result in hours of lost development time and can negatively impact time-sensitive product deployments. To address this resiliency problem, the GitLab Runner Docker executor now supports the use of multiple values for the `pull_policy` configuration, which is defined in the GitLab Runner `config.toml` file. You can use these values, or stacked image pull policies, to configure combinations of pull policies and mitigate the impact caused by lost connectivity. For example, if you configure `pull_policy =["always", "if-not-present"]`, the pull policy will `always` pull the image. However, if the target container registry is not available, the GitLab Runner Docker executor will fall back and use the `if-not-present` policy, which means a local copy of the image will be used for that pipeline job.
GitLab Runner[Use both branch and MR pipelines without duplication](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-environment-variables-reference):
> Previously it was not possible to run pipelines for branches first, then switch to [merge requests pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/) when the MR is created. Consequently, with some configurations, a push to a branch could result in duplicate pipelines if a merge request was already open on the branch: one pipeline on the branch and another for the merge request. Now you can use the new `$CI_OPEN_MERGE_REQUESTS` predefined environment variable in your CI configurations to switch from branch pipelines to MR pipelines at the right time, and prevent redundant pipelines.
Continuous Integration (CI)[Project configuration to control storage of latest artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#keep-artifacts-from-most-recent-successful-jobs):
> Keeping the latest artifact from the most recent successful job is a useful default behavior but can also result in significant amounts of storage usage. This can cause an unexpected surge in disk space usage if you have pipelines that generate large artifacts. To improve storage consumption management, you can now disable this behavior for any project in the settings.
>
> Coming up next, [gitlab#276583](https://gitlab.com/gitlab-org/gitlab/-/issues/276583) will allow you to entirely disable keeping the latest artifacts at the instance level.
Continuous Integration (CI)[GitLab Runner 13.8](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.8 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:
>
> - [Support named pipes for Windows Docker executor.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4295)
>
> #### Runner bug fixes:
>
> - [Fix cache upload on EKS 1.18 with IRSA.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27152)
> - [Fix cache push for failed jobs for Docker and Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27172)
> - [Azure cache on Kubernetes executor is not working.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27324)
> - [Fix FastZip to support artifacts for non-root users.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27398)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-8-stable/CHANGELOG.md).
GitLab Runner[Control job status using exit codes](https://docs.gitlab.com/ee/ci/yaml/#allow_failureexit_codes):
> You can use the `allow_failure` keyword to prevent failed jobs from causing an entire pipeline to fail. Previously, `allow_failure` only accepted boolean values of `true` or `false` but we've made improvements in this release, so now you can use the `allow_failure` keyword to look for specific script exit codes. This gives you more flexibility and control over your pipelines, preventing failures based on the exit codes.
Pipeline Authoring[Support variables for pipeline rules](https://docs.gitlab.com/ee/ci/yaml/#rulesvariables):
> Previously, the `rules` keyword was limited in scope and only determined if a job should be included or excluded from pipelines. In this release, you can now decide if certain conditions are met and subsequently override variables in jobs, providing you with more flexibility when configuring your pipelines.
Pipeline Authoring[Install NuGet packages from your group or subgroup](https://docs.gitlab.com/ee/user/packages/nuget_repository/#use-the-gitlab-endpoint-for-nuget-packages):
> You can use your project's Package Registry to publish and install NuGet packages. You simply add your project as a source using the NuGet CLI, Visual Studio, or the .NET CLI. For example, using the NuGet CLI you can run:
>
> ```
> nuget source Add -Name Package Registry[Improved SAST severity data for JavaScript vulnerabilities](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data):
> When available from our security scan analyzers, GitLab [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/) provides severity data for identified vulnerabilities. We recently updated our JavaScript analyzer, ESLint, to add support for severity and CWE data. This data will help increase the usability and accuracy of [Security Approval Rules](https://docs.gitlab.com/ee/user/application_security/#security-approvals-in-merge-requests) as fewer vulnerabilities will report 'Unknown' severity. Additionally, this data is shown on vulnerability detail pages providing more information and links to relevant information about vulnerabilities making it easier for developers to understand and remediate issues.
> In the future, we will [augment other analyzers missing vulnerability metadata](https://gitlab.com/groups/gitlab-org/-/epics/4004) and add a mechanism to allow [customized vulnerability metadata](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) enabling organizations to tailor results to match their risk profiles.
SAST