GitLab 13.8 Release

Allow GitLab.com group owners to bypass SSO enforcement

Allow GitLab.com group owners to bypass SSO enforcement

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.

Group webhook for members (edit, remove)

Group webhook for members (edit, remove)

In GitLab 13.7, we introduced a webhook 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.

Support for predefined variables in CI include section

Support for predefined variables in CI include section

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 in the include: section of your .gitlab-ci.yml file. This change is part of a bigger solution to bring better separation of duties control to your GitLab CI/CD pipelines.

Display all available quick actions in autocomplete

Display all available quick actions in autocomplete

When you enter / into a description or comment field, all available 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.

Group issues by label in the iteration report

Group issues by label in the iteration report

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.

Disable Operations features on a project

Disable Operations features on a project

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.

Optional sections for code owners

Optional sections for code owners

Code owner 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.

Rate limit dry run mode and bypass mechanism

Rate limit dry run mode and bypass mechanism

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 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. This allows you to better support trusted services.

Finally, you can configure specific users to bypass the rate limiter. This allows you to better support trusted users accessing your GitLab instance.

Configure multiple image pull policies for Docker executor

Configure multiple image pull policies for Docker executor

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 13.8

GitLab Runner 13.8

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.

Runner bug fixes:

• Fix cache upload on EKS 1.18 with IRSA.
• Fix cache push for failed jobs for Docker and Kubernetes executor
• Azure cache on Kubernetes executor is not working.
• Fix FastZip to support artifacts for non-root users.

The list of all changes is in the GitLab Runner CHANGELOG.

Support variables for pipeline rules

Support variables for pipeline rules

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.

Install NuGet packages from your group or subgroup

Install NuGet packages from your group or subgroup

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 <source_name> -Source "https://gitlab.example.com /api/v4/projects/<your_project_id>/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

This works great if you have a small number of projects. But if you have multiple projects nested within a group, you might quickly find yourself adding dozens or even hundreds of different sources. For large organizations with many teams, it’s common for a team to publish packages to their project’s Package Registry alongside the source code and pipelines. But, they also need to be able to easily install dependencies from other projects within their organization.

Moving forward, you can install packages from your group so you don’t have to remember which package lives in which project. Simply add your group as a source for NuGet packages and you can install any of the group’s packages.

nuget source Add -Name <source_name> -Source "https://gitlab.example.com /api/v4/groups/<your_group_id>/-/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

We hope this feature makes sharing dependencies between projects a little bit easier.

Improved pipeline status email subject line

Improved pipeline status email subject line

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.

Upload metrics images directly to incidents

Upload metrics images directly to incidents

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.

Active scan mode in on-demand DAST scanner profile

Active scan mode in on-demand DAST scanner profile

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.

Improved SAST severity data for JavaScript vulnerabilities

Improved SAST severity data for JavaScript vulnerabilities

When available from our security scan analyzers, GitLab Static Application Security Testing 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 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 and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.

Compare repositories and validate if they are the same

Compare repositories and validate if they are the same

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.

GitLab chart improvements

GitLab chart improvements

In GitLab 13.8, we added the ability to specify multiple virtual storages within our Praefect chart. If you have enabled 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, which provides guidance on reconnecting existing PersistentVolumeClaims to previous PersistentVolumes.

• GitLab Pages is now available for Kubernetes deployments
• Praefect now supports multiple virtual storages.
• The registry version has been updated to 2.13.1-gitlab

Single-node instances will now upgrade to PostgreSQL 12 by default

Single-node instances will now upgrade to PostgreSQL 12 by default

In GitLab 14.0, we plan to require PostgreSQL 12. PostgreSQL 12 offers significant indexing and partitioning benefits, 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.

Multi-node instances, and any Geo secondaries, will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.

Improved file searching in Advanced Search

Improved file searching in Advanced Search

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 search more flexible.

Performance improvements

Performance 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.
• Using GraphQL for the vulnerability state dropdown.
• Fixing N+1 queries with loading group issues with GraphQL.
• Enabling QueryCache for LoadBalancing.
• Swapping base audit_events table with a partitioned copy.

Busy status indicator

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.

Migrate Groups directly between instances

Migrate Groups directly between instances

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.

Welcome email for SAML and SCIM provisioned accounts

Welcome email for SAML and SCIM provisioned accounts

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.

Export requirements to a CSV file

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.

Approval Rule information for Reviewers

Approval Rule information for Reviewers

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.

Link source merge requests for squash and merge commits

Link source merge requests for squash and merge commits

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.

Quickly edit Wiki’s sidebar

Quickly edit Wiki’s 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, 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.

Use rich output for Jupyter notebooks

Use rich output for 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.

Control job status using exit codes

Control job status using exit 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.

Project configuration to control storage of latest artifacts

Project configuration to control storage of latest artifacts

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 will allow you to entirely disable keeping the latest artifacts at the instance level.

Use both branch and MR pipelines without duplication

Use both branch and MR pipelines without duplication

Previously it was not possible to run pipelines for branches first, then switch to merge requests 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.

GitLab Terraform Provider 3.4 updates

GitLab Terraform Provider 3.4 updates

If you use Terraform to set up GitLab, we are happy to announce version 3.4.0 of the GitLab Terraform Provider. 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.

Manage Terraform state files through the UI

Manage Terraform state files through the UI

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.

API Fuzz Testing results now visible in Security Dashboard

API Fuzz Testing results now visible in Security Dashboard

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.

Add DAST.latest.gitlab-ci.yml template

Add DAST.latest.gitlab-ci.yml 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.

Site validation for on-demand scans

Site validation for on-demand scans

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.

Geo support for PostgreSQL high-availability in Alpha

Geo support for PostgreSQL high-availability in Alpha

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 support for highly available PostgreSQL configurations using Patroni. We’ve upgraded Patroni to 2.0.1, added failover documentation, and fixed a number of bugs.

Omnibus improvements

Omnibus improvements

• Process related metrics have been removed from gitlab-exporter. GitLab now exports these directly.
• A patroni_role has been added to easily configure Patroni nodes for scaled GitLab deployments.
• Added fallback to postgresql[X] settings 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.
• GitLab 13.8 includes Mattermost 5.30, an open source Slack-alternative whose newest release includes improvements to the Matterpoll plugin, deprecation of PostgreSQL v9.x, and more.

Faster issue searching in Advanced Search

Faster issue searching in Advanced Search

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.

Bug fixes

Bug fixes

Some of the notable bug fixes in GitLab 13.8 are:

• Container Scanning no longer reported the analyzer version.
• Long titles were misaligned on the Pipeline Security tab in vulnerability reports.
• Inline code coverage was not loading with self-closing source tag in cobertura report.
• Grouping/swimlanes choice should persist after board has been edited.
• LFS issue when using GitLab Geo and location-aware Git URL.
• Fixed pipeline intermittent lint failures.