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.

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.

Scope a board to the current iteration

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, 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.

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

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.

Rebase quick action for merge requests

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 with the benefit of a simpler linear Git history.

GitLab 13.8 brings the ability to execute the rebase quick action in merge requests, allowing you quickly invoke the rebase Git utility.

On a merge request comment, type /rebase and click the Comment button. It’s that simple.

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

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 developer 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.

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

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.

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.

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.

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.

Send an email to an issue

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.

Designate optional sections in the codeowners file

Code owner sections allow multiple teams to configure their own code owners independently in the same file. This means teams can be assigned as code owners in their own section so that each team is added as a distinct reviewer in merge requests. 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 a changes from getting merged.

GitLab 13.8 introduces the ability to designate optional sections in your code owners file. Simply prepend the section name with the caret ^ character and the section will be treated as optional. This means, related change 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

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.

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.

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

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.

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, beside many smaller enhancements and a few bug fixes.

Alpha Geo support for PostgreSQL high-availability

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.

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.