GitLab.org/GitLab: Release v15.1.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 15.1
Released: 2022-06-22
License: MIT
Release Assets:
[Improved SAML Group Link robustness on GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html#automatic-member-removal) (SaaS only):
> Previously, GitLab.com group maintainers had to ensure they created group links for all users that would sign in using SAML. Otherwise,
> users that aren't in any linked groups could authenticate successfully but would immediately have their access and SAML identity removed.
>
> Now, instead of being removed, those GitLab.com users are automatically assigned the default role. This alleviates the burden from the group
> maintainer to have to make sure there is a group link for every user.
User Management[GitLab.com sign-in for GitLab Workflow for VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/tree/main#setup) (SaaS only):
> Getting started with [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for VS Code has been challenging: install the extension, only to learn you needed to follow several extra steps to set the extension up properly. The most difficult aspect of getting started was generating a personal access token with the right scope and adding it to the extension.
>
> Release [v3.47.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3470-2022-06-08) of GitLab Workflow now supports OAuth for GitLab.com, removing the need to manually generate a token. This is a huge step in making it easier for you to start using GitLab inside of VS Code.
Editor Extension[Enhancing visibility into Value Stream with DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html):
> With the addition of the four [DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html) tiles to the [Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) dashboard, you can now track team performance and value flow from ideation to customer delivery.
>
> Additionally, we added a new trend chart for the DORA [Time to restore service](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) metric to provide insights into software stability and reliability trends. This new chart shows information about how long it takes an organization to recover from a failure in production.
>
> This is the third DORA chart that's available out of the box in GitLab. We plan to keep improving the visibility into DORA metrics and also add charts for the fourth metric: Change failure rate.
Value Stream Management, Continuous Delivery[View your runners' upgrade status](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners):
> As the number of installed runners in your organization increases to hundreds or thousands, it becomes more challenging to determine which runners are outdated. Failing to update the version of GitLab Runner that your runners are using doesn't just mean you aren't using the latest features--it could also mean that you aren't taking advantage of security fixes.
>
> In the Admin Area, you can now identify at a glance which runners in your environment are outdated. Badges indicate whether an upgrade is recommended (for patches) and or an upgrade is available (for a minor or major upgrade). This feature makes it easier to maintain your runner fleet and mitigate the risks of using outdated versions.
GitLab Runner[FIPS-enabled Red Hat UBI Dependency Scanning image](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#fips-enabled-images):
> Dependency Scanning for Java (`gemnasium-maven`) is now available on a FIPS-enabled Red Hat UBI image. When FIPS mode is enabled, this image uses the OpenJDK packages for RedHat UBI 8 instead of the non-FIPS-compliant `asdf-java` package that is used by default. When FIPS mode is enabled, only Java versions 7, 11, and 17 are supported.
>
> To begin scanning using the FIPS-compliant Dependency Scanning image, simply [include the Dependency Scanning template](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration) in your CI/CD file and set the `DS_IMAGE_SUFFIX` variable to `"-fips"`.
Dependency Scanning[Optionally ignore scanning NPM development dependencies](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning):
> GitLab's Dependency Scanner analyzes vulnerabilities in application libraries that are used in a project, regardless of whether those libraries are regular dependencies or development dependencies. Some users would like to focus only on regular dependencies, ignoring any vulnerabilities found in the development dependencies.
>
> Excluding these development dependencies from scanning is now possible for NPM projects by setting the `DS_INCLUDE_DEV_DEPENDENCIES` variable to `"false"`. Open issues to extend this support to future package managers can be tracked in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/2743).
Dependency Scanning[Native Geo support for Object Storage replication is Generally Available](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> After extensive testing and fixing a few outstanding issues, native Geo support for object storage replication is now [generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga). Geo now natively supports replicating data in object storage such as LFS objects, job artifacts, and uploads. Previously, Geo could be configured to work with object storage, however the replication of the content was always left to the object storage provider. This imposed limitations when users relied on local storage appliances that do not support any replication logic.
>
> You can use Geo to replicate your data across different object storage providers in different regions (for example Amazon in Europe and Microsoft in the United States), as well as use local storage (for example through MinIO) and use Geo to replicate data to secondary sites.
>
> [Verification of data](https://gitlab.com/groups/gitlab-org/-/epics/8056) will be added in a later iteration.
Geo-replication, Disaster Recovery[Geo improves observability with links to replication views](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#step-6-verify-proper-functioning-of-the-secondary-site) (self-managed only):
> Geo links directly to the replication views on the secondary site for each data type from the primary site's admin dashboard. It is now possible to drill down to the list of individual objects for each data type on a secondary using the clickable links on the primary site's admin dashboard.
>
> This will help troubleshoot replication and verification issues at secondary sites, allowing system administrators to trigger resync and re-verify any objects failing to sync. It also improves overall observability of the replication and verification process by showing details of progress with information such as next sync attempt, last successful sync, and verification times for each object.
Geo-replication, Disaster Recovery[Geo supports OCI container images](https://docs.gitlab.com/ee/administration/geo/replication/docker_registry.html) (self-managed only):
> With GitLab 15.1, Geo supports replication of [OCI container image format](https://github.com/opencontainers/image-spec/blob/main/spec.md). OCI container images have been growing in popularity, and you are now able to replicate those images across Geo sites, similar to Docker manifest V1 and V2 images.
Geo-replication, Disaster Recovery[Geo proxying support for site-specific URLs](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> In GitLab 14.6, Geo allowed secondary sites to transparently proxy write requests to the primary site while accelerating most read requests. Until now, this feature required configuring [a unified URL](https://docs.gitlab.com/ee/administration/geo/secondary_proxy/#set-up-a-unified-url-for-geo-sites).
>
> In GitLab 15.1, Geo's proxying feature for the web UI works by default with secondary site-specific URLs. Customers who prefer maintaining different URLs for sites can now take advantage of a complete web UI experience.
Geo-replication[SAML Group Sync for self-managed GitLab](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html):
> You can now map a group in your identity provider to a self-managed GitLab group using SAML group links. Previously, this feature was only available for GitLab.com. Group memberships are updated when a user logs into GitLab through their SAML provider.
>
> This new functionality decreases the workload for GitLab administrators and reduces onboarding time for group members.
Authentication and Authorization[More `kubectl` calls for the agent CI/CD workflow](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html) (self-managed only):
> If you use the GitLab agent for Kubernetes with GitLab CI/CD, previously you couldn't use `kubectl exec`, `attach`, `cp`, or `port-forward` calls. GitLab now supports these calls on top of the SPDY protocol. If your load balancer or reverse proxy supports SPDY, you can now use `kubectl exec`, `attach`, `cp`, or `port-forward` in your CI jobs. Both the Helm Chart and Linux (Omnibus) installations of GitLab use NGINX and are configured to support SPDY out of the box.
>
> Unfortunately, some cloud providers do not support SPDY. GitLab is [working with the Kubernetes community to ship Websockets support](https://github.com/kubernetes/kubernetes/pull/110142) in Kubernetes, which will be the solution for many cloud-hosted GitLab instances, including GitLab SaaS.
Kubernetes Management[GitLab agent for Kubernetes supports proxied connections](https://docs.gitlab.com/ee/user/clusters/agent/install/index.html#use-the-agent-behind-an-http-proxy):
> Many users require a proxy to connect Kubernetes clusters to GitLab. Previously, the default installation method for the GitLab agent for Kubernetes did not support proxied connections. Now, you can use the `HTTP_PROXY` environment variable in the `agentk` Helm package to support proxied connections.
Kubernetes Management[Agent server for Kubernetes enabled by default in the Helm chart](https://docs.gitlab.com/ee/administration/clusters/kas.html) (self-managed only):
> The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.8, we enabled the agent server for Omnibus based installations.
>
> The feature has matured in the past few months, so we are now making the agent server enabled by default in the GitLab Helm chart as well to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.
Infrastructure as Code[Prevent users from using known insecure public keys](https://docs.gitlab.com/ee/security/ssh_keys_restrictions.html#block-banned-or-compromised-keys):
> When you attempt to add a new SSH key to your GitLab account, the key is checked against a list of SSH keys that are known to be compromised. Users can't add keys from this
> list to any GitLab account. This helps to secure your GitLab instance.
>
> Thank you [hackercat](https://gitlab.com/kyrie.31415926535) for your contribution!
Credential Management[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 15.1 includes [Mattermost 6.7](https://mattermost.com/blog/mattermost-v6-7-is-now-available/), whose newest release includes Playbooks task due dates and more! This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
> - Debian 9 (stretch) will reach end of life for long term support in June 2022. Therefore, we will stop building packages for Debian 9 (stretch) in GitLab 15.1.
Omnibus Package[API includes additional detail about who added members](https://docs.gitlab.com/ee/api/members.html):
> The members API now returns more information about who added a user to a project or group in the new `created_by` field.
>
> Thank you [Rémy Jacquin](https://gitlab.com/remyj38) for your contribution!
Authentication and Authorization[Retrieve PAT by ID using API](https://docs.gitlab.com/ee/api/personal_access_tokens.html#get-single-personal-access-token-by-id):
> Users can now retrieve their personal access tokens (PATs) by the PAT ID.
> Previously, users could only list all their personal access tokens using the API.
> There was no endpoint to support querying them one by one.
>
> Thanks to [Andreas Deicha](https://gitlab.com/TrueKalix) for their contribution!
System Access[Improved insights discovery in Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html):
> We've made several enhancements to how you view data for each stage of the [Value Stream Analytics](https://gitlab.com/gitlab-org/gitlab/-/value_stream_analytics) dashboard. In the stage table, we added the **Last event** column to show the most recent workflow event, and you can now sort items by duration.
>
> These changes make it easier for you to rearrange the events and discover insights faster. These insights could be in detecting bottlenecks that are slowing down delivery, or finding opportunities to reduce the time spent on each stage of the software supply chain.
Value Stream Management[Create annotated tags with the Releases API](https://docs.gitlab.com/ee/api/releases/#create-a-release):
> Previously, you were only able to create lightweight tags when using the Releases API to create a release. With this update, you can now add an optional `tag_message` parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.
Release Orchestration[Create annotated Tags with the GraphQL Release API](https://docs.gitlab.com/ee/api/graphql/reference/#mutationreleasecreate):
> Previously, you were only able to create lightweight tags when using the GraphQL API to create a release. With this update, you can now add an optional `tagMessage` parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.
Release Orchestration[Deploy keys by user API](https://docs.gitlab.com/ee/api/deploy_keys.html#list-project-deploy-keys-for-user):
> Previously, to enable deploy keys for a group of projects, administrator access was required to retrieve the `id` of the deploy key. This release adds a new API endpoint (`GET /users/:id_or_username/project_deploy_keys`) to retrieve all the keys accessible by a given user, so you can complete this task without waiting for an administrator. In a future [iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/365466), the API will also include public deploy keys.
Continuous Delivery, Secrets Management[Force stop an environment](https://docs.gitlab.com/ee/api/environments.html#stop-an-environment):
> In 15.1, we added a `force` option to the stop environment API call. This allows you to delete an active environment without running the specified `on_stop` jobs in cases where running these defined actions is not desired.
Environment Management[Allow `CI_JOB_TOKEN` authentication for Release Links API](https://docs.gitlab.com/ee/api/releases/links.html):
> Previously, the Release links API only accepted a personal access token or a project access token for authentication. With this update, a `CI_JOB_TOKEN` is now accepted for authentication to use with the API to manipulate GitLab Release links.
>
> Thank you [Timo Furrer](https://gitlab.com/tuxtimo) for your awesome contribution!
Secrets Management, Release Orchestration[Rendered images in Python notebook MRs](https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/#cleaner-diffs-and-raw-diffs):
> Python notebooks are key to data scientists' and machine learning engineers' workflows. These files commonly display charts and graphs via static images to help visualize the notebook.
>
> With this release, we now render these images in the merge request and commit view enabling a better user experience when reviewing code changes including Python notebooks with images.
Code Review[Block Git access protocols at group level](https://docs.gitlab.com/ee/user/group/#restrict-git-access-protocols):
> To improve security, you can now block Git access protocols that you don't use at the group level. This is similar to the GitLab administrator setting, but can now be set per group. By default, both HTTP(S) and SSH are enabled. In your group's **Settings > General > Permissions**, scroll to **Enable git access protocols** and remove any protocols you don't use.
Source Code Management[Retry a downstream pipeline from the pipeline graph](https://docs.gitlab.com/ee/ci/pipelines/):
> Previously, to retry a downstream pipeline, you had to navigate to the pipeline and select retry. This worked, but was a challenging experience when there were multiple downstream pipelines. You had to go into every individual pipeline you wanted to retry and find the retry option, which was cumbersome.
>
> In this release, we've improved the user experience by adding an option to retry downstream pipelines directly from the pipeline graph, without the need to go into each pipeline's details page.
Pipeline Authoring[View shared runner usage per project in a group](https://docs.gitlab.com/ee/ci/pipelines/compute_minutes.html#view-cicd-minutes-used-by-a-group):
> Using shared SaaS runners for public projects have the same CI/CD minutes limits as the corresponding tier the project is on. Users managing groups could see the total runner usage for the entire group, but could not see the usage for individual projects in one place. This made it hard to identify which projects within a group were using the most CI/CD minutes.
>
> Now you can see the SaaS runner usage for the group by project, the same as you can in a personal namespace. It is now easier to find the projects that are using the most CI/CD minutes and, if necessary, make their pipelines more efficient.
Continuous Integration (CI)[GitLab Runner 15.1](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 15.1 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD 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:
>
> - [Use Podman as the container runtime in the Runner Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29108)
> - [Add Software Attestations (metadata) to enable SLSA 2 in GitLab CI](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28940)
>
> #### Bug Fixes:
>
> - [Kubernetes executor ignores Docker `ENTRYPOINT` for the runner helper image](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28807)
> - [Docker Hub image for GitLab Runner 15.0.0 has only `amd64`, not `arm64` or `ppc64le`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29076)
GitLab Runner[SLSA-2 attestation included for build artifacts](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-attestation):
> [Supply-chain Levels for Software Artifacts (SLSA)](https://github.com/slsa-framework/slsa) is a security framework that helps ensure the security and integrity of your software supply chain. By default, GitLab Runner is now capable of generating and producing SLSA-2 compliant attestation metadata for build artifacts.
>
> If the artifact is stored in a registry, then the attestation metadata is stored alongside the artifact in that registry. Otherwise, the metadata is in rendered in a plain text `.json` file that's stored with the artifact.
>
> This new attestation information can help you more easily verify that your build artifacts have not been tampered with. To enable this feature, simply set `RUNNER_GENERATE_ARTIFACTS_METADATA = "true"` in your `.gitlab-ci.yml` file.
GitLab Runner[Link to included CI/CD configuration from the pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/):
> A typical CI/CD configuration uses the `include` keyword to import configuration stored in other files or CI/CD templates. When editing or troubleshooting your configuration though, it can be difficult to understand how all the configuration works together because the included configuration is not visible in your `.gitlab-ci-yml`, you only see the `include` entry.
>
> In this release, we added links to all included configuration files and templates to the pipeline editor. Now you can easily access and view all the CI/CD configuration your pipeline uses, making it much easier to manage large and complex pipelines.
Pipeline Authoring[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab Static Analysis includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.1 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - Kics analyzer updated to version 1.5.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v202) for details.
> - Add 82 new queries (rules) for Ansible, CloudFormation, Docker Compose, Kubernetes, and Terraform
> - Fix/update existing queries
> - Fix bugs in scanning and analysis
> - Improve performance
> - Secret Detection analyzer updated for better offline support and easier debugging. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v404) for details.
> - Improve logging
> - Use checked-out copy of the repository if `git fetch` fails
> - Fall back to scanning the latest commit if automatic diff detection fails
> - Security Code Scan analyzer updated to improve logging. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/blob/master/CHANGELOG.md#v342) for details.
> - Semgrep analyzer updated to use the latest version of GitLab-managed rulesets. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v301) for details.
> - Remove incorrect mapping to Gosec rule ID G104
> - Add rule G402 to detect use of TLS versions before 1.2
> - SpotBugs analyzer updated to SpotBugs version 4.7.0 and find-sec-bugs version 1.12.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v310) for details.
> - Update `gradle` and `grails` to support Java 17
> - Set Java 17 as the system-wide default version
> - Use 'assemble' task for Gradle projects, instead of 'build', to support custom `GRADLE_CLI_OPTS` (see [issue #299872](https://gitlab.com/gitlab-org/gitlab/-/issues/299872))
> - Add additional detection rules
>
> If you [include the GitLab-managed SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/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](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). 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.
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2022/05/22/gitlab-15-0-released/#static-analysis-analyzer-updates).
Code Quality, SAST, Secret Detection[Container Scanning analyzer updates](https://docs.gitlab.com/ee/user/application_security/container_scanning):
> GitLab Container Scanning supports both the Trivy and Grype analyzers. The following analyzer updates were published during this release milestone:
>
> - Trivy analyzer updated to version 0.28.1.
> - Grype analyzer updated to version 0.38.0.
> - Added support for detecting vulnerabilities in .NET packages when the `CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"` variable is set.
>
> These updates bring additional coverage, bug fixes, and improvements.
Container Scanning