GitLab 14.10 Release

Importing from GitHub defaults to the current group path

Importing from GitHub defaults to the current group path

When importing from GitHub, this milestone changes the default destination for imported projects to the contextual namespace of the GitLab group from which you started the import. Previously, GitHub projects imported to your personal namespace. This usability enhancement helps users import projects in a more intuitive way and doesn’t place imported projects in confusing locations.

Incremental repository backups reduce backup time

Incremental repository backups reduce backup time

We are pleased to offer our self-managed customers an opportunity to use our preliminary incremental backup offering. After you take at least one full backup, you can run subsequent incremental backups that only pack repository changes since the last backup into the backup bundle. This dramatically reduces backup time.

While this is available now, we want to clarify that each incremental backup overwrites the last incremental backup, and remind you that this is our MVC.

Please feel free to try out this exciting new feature and don’t hesitate to provide feedback!

See our Repository level incremental backup epic for updates on progress on this feature!

Create pipeline schedules for tags in the UI

Create pipeline schedules for tags in the UI

Previously, if you wanted to create a pipeline schedule for tags, you had to use the API. The simpler method of using the pipeline schedules UI could only be used for branches.

Now, when you use the pipeline schedules UI, you can choose from either branches or tags as needed, and no longer need to use the API! Thanks @KevSlashNull for this contribution!

GitLab Runner 14.10

GitLab Runner 14.10

We’re also releasing GitLab Runner 14.10 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:

• Configure artifact download path
• Script line timestamp improvements

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

Install the agent for Kubernetes with Helm

Install the agent for Kubernetes with Helm

The GitLab agent for Kubernetes has a component that needs to be installed into the user cluster. Previously, we provided a Docker-based one-liner installer and a Kpt-based advanced installation method. As Helm is an often requested method for installing Kubernetes applications, we are replacing the Docker-based installer with a Helm package.

Thanks to Eamonn McCudden’s (@emctl) contribution, the GitLab agent for Kubernetes can be installed into a user cluster from a Helm package. This facilitates the installation of the agent into the cluster as well as automating with Terraform. We have replaced the Docker-based installation method with the new Helm package as we expect users to have helm installed on the local machines.

The Helm package exists on both the charts.gitlab.io and ArtifactHUB repositories.

Upload metric screenshots to an Alert

Upload metric screenshots to an Alert

GitLab 13.2 introduced the metrics tab in GitLab alerts. However, with the deprecation of GitLab Managed Apps and alerts on the Metrics page, metrics no longer automatically populate on new alerts and are difficult to support on old ones. This release completes the deprecation of the old metrics functionality, and introduces the ability to add a screenshot to alerts, similar to how screenshots can be added to incidents. Having a screenshot of the metric that triggered the alert helps responders triage alerts more efficiently.

Manually create a Vulnerability Record

Manually create a Vulnerability Record

Vulnerability Management in GitLab processes and aggregates security findings from our many Secure scanners, and can seamlessly incorporate results from integrated 3rd-party scanners. While this provides valuable security information in a unified experience, it limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools.

We’re introducing the ability to manually create vulnerability records to greatly expand the use cases Vulnerability Management can handle. Leveraging our recently-released ability to create vulnerability records through the API, making a new vulnerability record is as simple as entering a few required pieces of information. With manually created vulnerability records you can provide additional details supported by vulnerability records, including the severity, identifiers and suggested solution. You can view manually created records in the Group, Project, and Security Center Vulnerability Reports. And you can move records through your triage and remediation workflows like you would any scanner-detected vulnerability.

Security policy management user experience improvements

Security policy management user experience improvements

Several initiatives to improve the user experience for managing security policies were completed in GitLab 14.10:

• A new workflow for selecting the policy type when creating a new policy.
• Validation of the YAML syntax when saving changes, including specific details when errors are encountered.
• A more consistent experience for the policy details drawer across policy types, including a text description of the policy.
• Previously, only project Owners were able to see information about the policy management project. Other roles can now see a button on the Policy page indicating the policy management project’s location.
• Various other improvements to performance, design, and handling of error states.

To get started with GitLab Security Policies, navigate to a project > Security & Compliance > Policies.

GitLab chart improvements

GitLab chart improvements

• GitLab 14.10 includes a fix to Sidekiq’s health_checks.port, setting the value to 3808 by default. This ensures the Sidekiq pods will listen separately for metrics and health checks, so Kubernetes probes behave appropriately.

View history of all project imports on a single page

View history of all project imports on a single page

The new Project import history page lists all project imports, regardless of where they were imported from. This view consolidates information that was previously scattered on the import pages of each individual importer.

Having all the details about previous imports in one view gives you a single place to find and review the status of all previous imports. This includes details on imports that failed, so that you can verify that you successfully imported all the intended projects.

CI/CD Limits set at the Instance Level

CI/CD Limits set at the Instance Level

To contain resource usage in support of instance stability, GitLab administrators of instances with high CI/CD usage might want to add limits for specific CI/CD events. This could be to set the maximum number of jobs in a single pipeline, the maximum number of concurrent jobs in active pipelines, or the maximum number of scheduled pipelines per project.

GitLab instance administrators can now set these limits (and others) directly in the instance’s Admin Area panel.

Expanded view of group runners

Expanded view of group runners

Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace. To view the new UI, on the left sidebar, select CI/CD. This view includes the number of online, offline, and stale runners associated with the group and subgroups.

Improved pipeline variables inheritance

Improved pipeline variables inheritance

Previously, it was possible to pass some CI/CD variables to a downstream pipeline through a trigger job, but variables added in manual pipeline runs or by using the API could not be forwarded.

In this release we’ve added a new trigger:forward keyword to control what things you forward to downstream parent-child pipelines or multi-project pipelines, which provides a flexible way to handle variable inheritance in downstream pipelines.

Multiple approval rules for deployment approvals API

Multiple approval rules for deployment approvals API

Previously, deployment approvals supported a simple model where the ability to execute a deployment and approve a deployment were both controlled with a single list of users. With this update, you have more flexibility and granularity with these rules and can specify multiple levels of control using the API. One type of model that can now be supported is where there is separation of duties between deployment executors and approvers in your organization. Another supported model is where approval is needed separately from multiple levels, such as a QA tester group and a security group.

Faster, easier Java scanning in SAST

Faster, easier Java scanning in SAST

GitLab Static Application Security Testing (SAST) now uses Semgrep to scan Java code, building on previous support for Go (introduced in GitLab 14.4) and for JavaScript, TypeScript, and Python (introduced in GitLab 13.12).

The Semgrep-based analyzer runs significantly faster—up to 7 times faster in our testing than the existing analyzer that’s based on SpotBugs. It also doesn’t need to compile your code before scanning, so it’s much simpler to use than SpotBugs.

The Static Analysis and Vulnerability Research teams worked together to translate rules to the Semgrep format, preserving most existing rules. We also updated, refined, and tested the rules as we converted them.

If you use the GitLab-managed SAST template (SAST.gitlab-ci.yml), both Semgrep and SpotBugs now run whenever Java code is found. In GitLab Ultimate, the Security Dashboard combines findings from the two analyzers, so you won’t see duplicate vulnerability reports.

In a future release, as we announced, we’ll change the GitLab-managed SAST template (SAST.gitlab-ci.yml) to only run the Semgrep-based analyzer for Java code. The SpotBugs-based analyzer will still scan other JVM languages like Groovy, Kotlin, and Scala.

If you have any questions, feedback, or issues with the new Semgrep-based Java scanning, please file an issue, we’ll be glad to help.

Static Analysis analyzer updates

Static Analysis analyzer updates

GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 14.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.

• Gosec analyzer updated to version 2.11.0. See CHANGELOG for details.
  • Add rule for potential directory traversal through http.Dir("/")
  • Detect minimum TLS version even when declared in a different file within the package
• Kics analyzer updated to version 1.5.5. See CHANGELOG for details.
  • Add new rules
  • Fix existing rules
  • Delete redundant rules
• PMD analyzer updated to version 6.44.0. See CHANGELOG for details.
  • Add Java 18 support
  • Fix rules
• Secrets analyzer updated to version 8.6.1. See CHANGELOG for details.
  • Add entropy values to all findings
  • Skip content checks for rules that are only based on file paths
  • Add ability to skip a finding if gitleaks:allow is included in the same line as a detected secret
• Semgrep analyzer updated to version 0.86.5. See CHANGELOG for details.
  • Support Go 1.18 generics
  • Additional bug fixes and performance improvements

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.

Geo verifies CI job artifacts

Geo verifies CI job artifacts

Geo automatically verifies the data integrity of replicated CI job artifacts. This ensures that artifacts are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.

Omnibus improvements

Omnibus improvements

• GitLab 14.10 includes Mattermost 6.5, whose newest release includes custom groups, cross-team channel navigation, playbook import, export, and duplication, improved board sharing, Bitbucket integration, workplace optimization, improved onboarding experiences, Persian language support, plus more! This version also includes security updates and upgrade from earlier versions is recommended.