GitLab.org/GitLab: Release v13.11.0-ee

Name: GitLab

Owner: GitLab.org

Release: GitLab 13.11

Released: 2021-04-22

License: MIT

Release Assets:

 

[Group SAML Enforcement for Git activity](https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement) (SaaS only): Authentication and Authorization

> GitLab group maintainers can now enhance their group security by enforcing Group SAML for Git activity. Security-minded organizations want all GitLab activity to be protected and governed by their SAML Identity Provider. Currently, SAML SSO enforcement only applies to activity in the GitLab UI. Git CLI operations do not require an active SAML SSO session. When Git Group SAML SSO enforcement is enabled, users must have an active web SAML session to perform Git operations in the CLI.

#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)  

[Compliance pipeline configurations](https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration): Compliance Management

> We are thrilled to announce that it is now possible to define enforceable pipelines that will run for any project assigned a corresponding [compliance framework](https://docs.gitlab.com/ee/user/project/settings/#compliance-framework). > > For teams looking to implement compliance requirements in the pipeline workflow, they can now enforce even more separation of duties by setting up a single pipeline definition for a specific compliance framework. All projects using that framework will include the predefined pipeline automatically. Users extend, but cannot modify, the pipeline configuration in the downstream projects, ensuring that compliance steps are run the same way every time. > > This saves security and compliance teams time by eliminating the need to manually copy a pipeline configuration to every project that needs it and then monitoring to prevent edits or removal. It also helps development teams follow policies without requiring them to become experts in compliance. > > Defining a compliance pipeline configuration for compliance frameworks is a great way to ensure an organization consistently meets its regulatory requirements while saving everyone time and encouraging collaboration between security/compliance and development teams. > > Check out the [video walkthrough](https://www.youtube.com/embed/upLJ_equomw) to see its setup and implementation!

[Track DORA 4 lead time for changes metric](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#lead-time-charts): Continuous Delivery

> Measuring the efficiency of your software development lifecycle is an important step to grow DevOps adoption for any organization. In the previous milestone, we added API support for [lead time for changes](https://docs.gitlab.com/ee/api/dora/metrics.html#get-project-level-dora-metrics) at the project level. These metrics give you an indication of throughput so you know how long it takes for code to be committed and deployed to your production environment. In this release, you can now access this capability in the GitLab UI through the CI/CD dashboard, where a new graph will show the lead time for changes with the ability to view different time ranges, such as the last week, last month, or the last 90 days. In addition to the new graph, we have also added support for this API on the group level, allowing you to get aggregated lead time for changes metrics from all the projects that belong to the group.

[GPG keys available in the admin Credential Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html#review-existing-gpg-keys): Compliance Management

> You can now view GPG key information for your users in the admin area. This lets you quickly see what keys are stored > in GitLab, their ID, and if they are verified or not, to help you better understand how users could interact > with your GitLab instance. > > This is part of our continuing efforts to build out the [Credential Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html#credentials-inventory). > We have [many iterations](https://gitlab.com/groups/gitlab-org/-/epics/4110) planned to add more visibility, control, and value for your organization. We'd love your feedback on the epics and issues!

[DevOps Adoption metrics available at the group level](https://docs.gitlab.com/ee/user/group/devops_adoption/index.html): DevOps Reports

> The DevOps adoption table is a valuable feature for leadership to see which GitLab stages and features have been adopted by their teams. Up until this point, this feature could only be accessed through the Admin Area, which restricted access to administrators on self-managed instances of GitLab. This update brings DevOps adoption metrics to the group level, allowing more users to understand how and where they are adopting features across GitLab. This feature is currently disabled by default. To enable it, see [instructions in the documentation](https://docs.gitlab.com/ee/user/group/devops_adoption/index.html#enable-or-disable-group-devops-adoption). It will be enabled by default in the next release.

[SSH key expiration email notification](https://docs.gitlab.com/ee/ssh/#add-an-ssh-key-to-your-gitlab-account) (self-managed only): Compliance Management

> SSH keys that you add to the [Credential Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html) > can be configured with an expiration date to help ensure proper key rotation and limit ongoing > access to your instance. > > By default, GitLab will now check daily to see if any expiration dates are approaching. An email notification will be sent the week before, and the day before the key expires, to allow you to take any needed actions to update the key or any systems that rely on it.

##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)

[Filter requirements based on status](https://docs.gitlab.com/ee/user/project/requirements/#search-for-a-requirement): Requirements Management

> To know which areas of the product need additional testing or are incomplete, you can now filter your requirement list based on the status. Now, you and your team can readily see what work remains! > > As requirements can be satisfied through CI/CD pipeline jobs, the status of the requirement is always up to date.

#### [Premium](https://about.gitlab.com/pricing/premium/)  

[GitLab Agent for Kubernetes available on GitLab.com](https://docs.gitlab.com/ee/user/clusters/agent/)

> The GitLab Agent for Kubernetes is finally available on GitLab.com. By using the Agent, you can benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent. The Agent is the core building block of GitLab's Kubernetes integrations. The Agent-based integration today supports pull-based deployments and Network Security policy integration and alerts, and will soon receive support for push-based deployments too. > > Unlike the legacy, certificate-based Kubernetes integration, the Agent does not require opening up your cluster towards GitLab and allows fine-tuned RBAC controls around GitLab's capabilities within your clusters.

[Create custom compliance framework labels](https://docs.gitlab.com/ee/user/project/settings/#custom-compliance-frameworks): Compliance Management

> GitLab currently provides several [predefined compliance framework](https://docs.gitlab.com/ee/user/project/settings/#compliance-framework) > labels such as GDPR, HIPAA, PCI-DSS, SOC 2, and SOX. With this release, you can now add your > own custom frameworks. This enables you to customize your labels for your own specific > frameworks and processes. In the future, you will be able to create policies that can be > applied to projects based on this label.

[Export a user access report](https://docs.gitlab.com/ee/administration/admin_area.html#user-permission-export) (self-managed only): Audit Reports

> Compliance-minded organizations have a recurring requirement to audit the access their users have to company systems and resources. Previously, achieving this in > GitLab required building custom tooling with our [audit-related APIs](https://docs.gitlab.com/ee/administration/audit_reports.html#apis) > to assemble the data you needed. > > Now, you can simply click an `export` button in the admin area of your self-managed GitLab instance to retrieve a CSV file containing a list of each user and the groups, subgroups, > and projects they have access to. It is now much easier to audit your user access in a > lot less time.

[Environment-specific variables at the group level](https://docs.gitlab.com/ee/ci/variables/#add-a-cicd-variable-to-a-group): Secrets Management

> Many organizations prefer to specify secrets and other environment variables at the group level, as it aligns well with team boundaries or trust levels. Until now, the group-level environment variables affected all the environments, and this limited their usability in a lot of use cases. Today, we are releasing environment-specific variables at the group level. > > This change complements similar functionality at the project level. From now on, group maintainers can specify the environments where a given variable is to be applied.

[Audit Events now available to Developer+](https://docs.gitlab.com/ee/administration/audit_events.html#audit-events): Audit Events

> Audit logs are one of the most important elements of a system for compliance-minded organizations and their compliance programs. The audit logs provide visibility into user and system activity to help troubleshoot incidents, isolate who was responsible for an action, and allow organizations to compile evidence artifacts for auditors of certain processes. Previously, only Maintainers, Owners, and Administrators could access the [**Audit Events**](https://docs.gitlab.com/ee/administration/audit_events.html#audit-events) view. All other users were unaware these logs existed and did not have access to view their own activity, let alone maintain a compliance mindset within their organization. > > **Security & Compliance > Audit Events** is now available to users with Developer access and higher. Users with Developer access can only see their own activity, not the activity of other users (users with Maintainer access and higher continue to see both their own activity and the activity of other users). This change makes audit data accessible to more users and helps strengthen the compliance mindset of GitLab users.

[Geo supports Pipeline Artifacts](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only): Geo-replication, Disaster Recovery

> Geo now supports replicating and verifying [Pipeline Artifacts](https://docs.gitlab.com/ee/ci/pipelines/pipeline_artifacts.html) > to secondary sites, allowing distributed teams to access them from the > closest Geo site, which reduces latency and improves the overall user > experience. Geo automatically verifies the data integrity of replicated > [Pipeline Artifacts](https://docs.gitlab.com/ee/ci/pipelines/pipeline_artifacts.html). > This ensures that Pipeline 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.

##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)

[Instance and group description templates for issues and merge requests](https://docs.gitlab.com/ee/user/project/description_templates.html#set-group-level-description-templates): Issue Tracking

> Instead of manually updating the same [description template](https://docs.gitlab.com/ee/user/project/description_templates.html) across dozens of projects, you can now centrally manage and source your templates from a single repository. We've extended the [instance](https://docs.gitlab.com/ee/administration/settings/instance_template_repository.html) and [group file templates](https://docs.gitlab.com/ee/user/group/#group-file-templates) to include issue and merge request description templates. When you create a `.gitlab` directory in your file templates repository, description templates will be available to all projects that belong to the instance or group. Each group or subgroup can also set an additional template repository, which will enable templates from multiple file template repositories to cascade down to your subgroups and projects.

[Add iteration lists in Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#iteration-lists): Boards

> Boards now support creating iteration lists. Quickly move issues from one [iteration](https://docs.gitlab.com/ee/user/group/iterations/) to another on your planning board or [enable epic swimlanes](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes) to efficiently sequence an epic's issues across your upcoming iterations.

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[On-call Schedule Management](https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html): Incident Management

> Software services do not get "turned off" at the end of the business day. Your customers expect 24/7 availability. When things go wrong, you need a team (or multiple teams!) that can quickly and effectively respond to service outages. > > Being on-call can be a stressful job. To better manage stress and burn-out, most teams rotate this on-call responsibility. GitLab's **on-call schedule management** allows you and your team to create and manage schedules for on-call responsibilities. Alerts received in GitLab through an HTTP endpoint are routed to the on-call engineer in the schedule for that specific project.

#### Core  

[Re-authenticate for GitLab administration with Admin Mode](https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#admin-mode) (self-managed only): Authentication and Authorization

> GitLab now includes Admin Mode, which helps admins work safely from one account. When Admin Mode is not active, admins have the same privileges as regular users. Before running administrative commands, admin users must reverify their credentials. Admin mode increases instance security by protecting sensitive operations and data. > > Thank you Diego Louzán from Siemens for this contribution. Admin Mode wouldn’t have happened without his perseverance. This feature has been in the making for a year!

[Support for custom CA certificates when using the release CLI](https://docs.gitlab.com/ee/user/project/releases/index.html#use-a-custom-ssl-ca-certificate-authority): Release Orchestration

> Up to this point in time, if you were using GitLab self-managed, you could use the [release CLI](https://gitlab.com/gitlab-org/release-cli) with a public certificate, but not your own custom one. In GitLab 13.11, we have added support for custom certificate authority (CA) certificates by using the `ADDITIONAL_CA_CERT_BUNDLE` environment variable or the `--additional-ca-cert-bundle` flag. In addition, the `INSECURE_HTTPS` environment variable and the `--insecure-https` flag were added so that the client can skip verifying the server certificates, which would normally fail with a custom SSL certificate because it is not signed by a public CA.

[Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)](https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc): Cloud Native Installation

> GitLab is working to offer full support for OpenShift. To accomplish this, we have released the MVP [GitLab Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc). The operator aims to manage the full lifecycle of GitLab instances on Kubernetes and OpenShift container platforms. Currently, this is a [beta release](https://gitlab.com/groups/gitlab-org/-/epics/3444) and it is **not recommended for production use**. The next steps will be to make the operator generally available (GA). In the future the operator will become the recommended installation method for Kubernetes and OpenShift, although the GitLab Helm chart will still be supported. We welcome you to try this operator and [provide feedback on our issue tracker](https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/issues/131).

[Bring your own Prometheus for the best GitLab - Kubernetes integrated experience](https://docs.gitlab.com/ee/user/clusters/integrations.html#prometheus-cluster-integration): Kubernetes Management

> By integrating your cluster services with GitLab you can benefit from various GitLab features, like [Environment boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html), [Prometheus metrics](https://docs.gitlab.com/ee/operations/metrics/), and [application logs](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html). Previously, these features required you to use GitLab Managed Apps which did not suit the workflow and requirements of many of our users. > > With this release, you can integrate with Prometheus and Kubernetes through GitLab services and keep their maintenance on your end, following your own company processes and policies. We provide extensive documentation and a recommended workflow on how to install these applications if you are just getting started. You can still hold the deep metrics integrations available in GitLab as you had with GitLab Managed Prometheus.

[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only): Cloud Native Installation

> - The configuration option [`terminationGracePeriodSeconds`](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/) in Sidekiq is now available for the Sidekiq chart, which allows for better protection of long-running jobs during pod shutdown. > - Previously, there was no protection if users set the `SIDEKIQ_TIMEOUT` to a value higher than `terminationGracePeriodSeconds`. This would result in jobs that are continuing to run beyond 30 seconds to be forcibly stopped. With the new chart release, Sidekiq deployments can now have [differing timeouts](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/). > - Support for [IAM roles for service accounts](https://docs.gitlab.com/charts/advanced/external-object-storage/index.html#using-iam-roles-for-service-accounts) to access external object storage is now available.

[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only): Omnibus Package

> GitLab 13.11 includes [Mattermost 5.33](https://docs.mattermost.com/administration/changelog.html#release-v5-33-feature-release), which includes a soft delete when deleting a reaction in the reactions table. Also WebSocket handshakes done with HTTP version lower than 1.1 will result in a warning, and the server will transparently upgrade the version to 1.1 to comply with the WebSocket RFC. This facility will be removed in a future Mattermost version and it is strongly recommended to fix the proxy configuration to correctly use the WebSocket protocol.

[Register OAuth applications at the group level](https://docs.gitlab.com/ee/integration/oauth_provider.html#group-owned-applications): Authentication and Authorization

> Group owners can now register OAuth applications for a group. Previously, OAuth applications could only be registered by individual users or at the instance level. Making this functionality available at the group level reduces the administrative burden for instance administrators and removes the dependency on individual users for the configuration of OAuth applications. > > Thanks to the amazing work from GitLab contributor Jonas Wälter from Siemens, this feature is now available in 13.11.

[Update a deploy freeze period in the UI](https://docs.gitlab.com/ee/user/project/releases/#prevent-unintentional-releases-by-setting-a-deploy-freeze): Release Orchestration

> In GitLab 13.2, we added the ability to create a [deploy freeze](https://docs.gitlab.com/ee/user/project/releases/index.html#prevent-unintentional-releases-by-setting-a-deploy-freeze) period in the project's CI/CD settings. This capability helps teams avoid unintentional deployments, reduce uncertainty, and mitigate deployment risks. However, it was not possible to update deploy freezes. In GitLab 13.11, we are adding the ability to edit an existing deploy freeze. This way, you can update the freeze period to match your business needs.

##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)

[Active integrations now display separately](https://docs.gitlab.com/ee/user/project/integrations/overview.html): Integrations

> With over 30 integrations available today, it was becoming difficult to see which integrations were currently active on the settings page. > > Active integrations now display in a separate table at the top of the page, making it clear what you're using, and easier to find the integrations you care about most.

[Add standalone comments to merge request reviews](https://docs.gitlab.com/ee/user/discussions/#adding-a-new-comment): Code Review

> When you're reviewing changes, you may want to summarize your feedback, or comment on something unrelated to the specific changes. [Reviews](https://docs.gitlab.com/ee/user/discussions/#merge-request-reviews) in GitLab only allowed commenting on the changes or replying to existing comments, which meant that other kinds of comments had to be made after submitting the review. > > As part of your review process, you can now submit a general comment along with your replies or change-specific comments. General comments make it simple to provide feedback to the author and use [quick actions](https://docs.gitlab.com/ee/user/project/quick_actions.html) to update items across the merge request. > > Thanks to [Lee Tickett](https://gitlab.com/leetickett) for the contribution!

[Set default target project for merge requests in forks](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#set-the-default-target-project): Code Review

> After forking a project, it can be beneficial to use merge requests to make contributions to the upstream project. Previously, GitLab assumed that merge requests from your fork project would always target the upstream project. This can create missteps where code shouldn't be merged upstream, or users need to make changes prior to opening the merge request. > > GitLab now supports setting the default target project for merge requests that are created in fork projects. This streamlines contributions and helps avoid mistakes for users and teams who more commonly contribute to their fork project, instead of the upstream project.

[Welcome view for GitLab Workflow in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#setup): Editor Extension

> Getting started with the GitLab Workflow extension for Visual Studio Code (VS Code) requires several manual steps to connect it to GitLab. If the extension isn't set up correctly, or you're setting it up for the first time, it can be hard to verify you've configured it correctly. > > In the GitLab Workflow pane inside VS Code, there are now steps to help you get started. It also tells you if your current workspace doesn't contain a GitLab project.

[Cherry pick commits from fork to parent](https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html#cherry-pick-into-a-project): Source Code Management

> With GitLab 13.11, if you are a project member, you can now cherry-pick commits from downstream forks back into your project. We've added a new **Pick into project** section to the cherry-pick dialog, shown when you select **Options > Cherry-pick** on a commit's details page. > > Your community of contributors can contribute to your project, and your team no longer needs to manually download a fork's `.patch` file to pull in good changes from stale or unmaintained forks. > > Future enhancements include [cherry-picking commits from fork to fork](https://gitlab.com/gitlab-org/gitlab/-/issues/326771).

[Force push option for protected branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#allow-force-push-on-protected-branches): Source Code Management

> It's best practice to prevent `force push` on Git repos, but exceptional cases may occasionally require it. Temporarily removing branch protections in order to conduct a `force push` may not always be ideal as it requires maintainer access, and causes the settings for branch protection to be lost. > > GitLab 13.11 introduces a new **Allow force push** setting for protected branches, which enables users in the **Allowed to push** list to force push.

[Improvements to Jira Connect application configuration](https://docs.gitlab.com/ee/integration/jira/connect-app.html): Integrations

> When configuring the [GitLab.com for Jira](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud) application, you can now filter the available namespaces when linking them to your account, simplifying configuration for users with access to a large number of namespaces.

[Search within a settings page](https://docs.gitlab.com/ee/user/search/#search-settings): Navigation & Settings

> Finding the exact location of a GitLab setting can be challenging. Even if you know generally where to look, many of the settings views have multiple sections and dozens of individual configuration options. > > In this release, you can now use the search field in group, project, admin, and user settings to quickly pinpoint your desired configuration. Your search criteria will filter the current page down to display only relevant settings and even highlight occurrences of your search term on the page. > > In the future iterations, we are looking to extend this functionality to [search across all settings views](https://gitlab.com/groups/gitlab-org/-/epics/5198).

[Deep link directly to lines of code](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#highlight-lines): Web IDE, Pipeline Authoring

> Collaborating on long files is easier when you can share a link to a specific line of code. Previously, you could only link to a line number when viewing a file in the repository, but now you can also link to specific lines of code in the context of editing a file. Previously announced [in GitLab 13.10 for SaaS customers](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#deep-link-directly-to-lines-of-code), this feature is now available to everyone. > > To get a link to a specific line, click the icon in the gutter next to the line number, or append `#L` followed by the line number to the edit URL. The link will open the editor, scroll to the line, and highlight it for you. Try it out in the single-file editor, the Web IDE, and the Pipeline Editor! > > Tip: you can even create a link to multiple lines by appending a range to the link, like `#L87-98`, even though the UI doesn't support creating these (yet).

##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)

[Use multiple caches in the same job](https://docs.gitlab.com/ee/ci/caching/index.html#use-multiple-caches): Pipeline Authoring

> GitLab CI/CD provides a caching mechanism that saves precious development time when your jobs are running. Previously, it was impossible to configure multiple cache keys in the same job. This limitation may have caused you to use artifacts for caching, or use duplicate jobs with different cache paths. In this release, we provide the ability to configure multiple cache keys in a single job which will help you increase your pipeline performance.

[Optional DAG ('needs:') jobs in CI/CD pipelines](https://docs.gitlab.com/ee/ci/yaml/#needsoptional): Pipeline Authoring

> The directed acyclic graph (DAG) in GitLab CI/CD lets you use the `needs` syntax to configure a job to start earlier than its stage (as soon as dependent jobs complete). We also have the `rules`, `only`, or `except` keywords, which determine if a job is added to a pipeline at all. Unfortunately, if you combine `needs` with these other keywords, it's possible that your pipeline could fail when a dependent job does not get added to a pipeline. > > In this release, we are adding the `optional` keyword to the `needs` syntax for DAG jobs. If a dependent job is marked as `optional` but *not* present in the pipeline, the `needs` job ignores it. If the job is `optional` and present in the pipeline, the `needs` job waits for it to finish before starting. This makes it much easier to safely combine `rules`, `only`, and `except` with the growing popularity of DAG.

[Create initial configuration file from the pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html): Pipeline Authoring

> The pipeline editor is your one stop shop to build and test your CI/CD pipeline. Previously, the editor only worked if the `.gitlab-ci.yml` configuration file already existed in the root of your repository. In this release, we've added the ability to create an initial empty pipeline file from the pipeline editor page itself, so you can start authoring your pipeline immediately.

[GitLab Runner 13.11](https://docs.gitlab.com/runner): GitLab Runner

> We’re also releasing GitLab Runner 13.11 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: > > - [Caching is faster for Node.js projects](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1797) > - [Allow user to specify multiple pull policies for Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27298) > > #### Bug fixes: > > - [Permission errors when using `kubectl attach` and non-root user](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27107) > - [GID check in Docker executor uses wrong method](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27600) > - [Skip VM provisioning on creation failure for `docker+machine` executor.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27613) > - [Kubernetes executor does not expand image variable in build log](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25875) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-11-stable/CHANGELOG.md).

[Predefined CI/CD variable for commit author](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html): Continuous Integration (CI)

> Previously, if you needed to identify the author of a commit in a running CI/CD job, you had to add an extra API call to the job to retrieve it. Now, this information is readily available as the `CI_COMMIT_AUTHOR` predefined CI/CD variable. > > Thanks to [Craig Andrews](https://gitlab.com/candrews) for this contribution!

[Code Quality violations sorted by severity](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-widget): Code Quality

> Running Code Quality scans on your Projects can find dozens to thousands of violations. In the smaller view of the Merge Request widget, it can be hard to pinpoint the most critical issues to address first as you're sorting through a large number of code quality violations. > > Both the Code Quality Merge Request widget and the Full Code Quality Report now sort violations by Severity so that you can quickly identify the most important Code Quality violations to address.

##### [Package](https://about.gitlab.com/stages-devops-lifecycle/package/)

[Download Composer dependencies from version control](https://docs.gitlab.com/ee/user/packages/composer_repository/#install-a-composer-package): Package Registry

> You have two options when downloading Composer dependencies: `source` or `dist`. For stable versions, Composer uses `dist` by default and downloads the dependency as a `zip` file. However, you can also download it directly from version control. If `--prefer-source` is enabled, Composer downloads your dependency as a Git clone instead of as a packaged `zip` file. This is useful if you want to make a bug fix for a project and get a local Git clone of the dependency directly. > > Until recently, you could not use the `prefer-source` and related `preferred-install` commands and configurations when downloading Composer dependencies. This prevented many of you from using the GitLab Package Registry for your Composer dependencies. > > We are happy to announce that you can now download your Composer dependencies from source. Do so by simply adding the `prefer-source` option to your install command like this: `composer update --prefer-source`.

[Publish and install generic packages with SemVer](https://docs.gitlab.com/ee/user/packages/generic_packages/#publish-a-package-file): Package Registry

> You use the GitLab Package Registry to publish and share generic package files. You can do this using the command line, but it's likely that you use GitLab CI/CD to publish most of your files. > > Prior to GitLab 13.11, the GitLab validation on the file name prevented you from uploading a package with a semantic version (SemVer). This blocked many of you from using the Package Registry in your pipelines since SemVer is commonly used to mark files as related to a given release or branch. > > GitLab 13.11 relaxes the file name validation so you can use SemVer to name files. We hope this helps you to adopt the Package Registry and makes it easier to name, validate, and verify your generic packages.

[Share filtered views of the Package and Container Registries](https://docs.gitlab.com/ee/user/packages/package_registry/#view-packages): Package Registry

> You use the GitLab Package and Container registries to publish and share your project's dependencies. When you view your registry in GitLab, you can filter and sort the results to find and validate the item you are looking for. > > Before GitLab 13.11, you had no way to share a filtered view of the registry with your teammates. As a result, each team member had to spend time filtering their view. This was inefficient and introduced the risk that the wrong dependency may be installed. > > In GitLab 13.11, you can share your filtered view of the registry by simply copying the URL from your browser and sharing it with your team. We hope this change makes you more efficient.

[Use Composer v2 with the GitLab Package Registry](https://docs.gitlab.com/ee/api/packages/composer.html#v2-package-metadata): Package Registry

> You use [Composer](https://getcomposer.org/) to publish, share, and download your PHP dependencies to your GitLab Project. Six months ago, a new major version (v2) of Composer was launched with a variety of changes, including significant performance improvements, architectural updates, and runtime features. You can read more about the changes [here](https://blog.packagist.com/composer-2-0-is-now-available/). > > Until recently, you couldn't take advantage of these improvements because the GitLab registry didn't support Composer v2. This prevented some of you from using the GitLab registry at all. As an MVC, we focused on adding support for the mandatory parameter `metadata-URL`. We added a new endpoint `GET group/:id/-/packages/composer/p2/:package_name`, which returns the metadata for all packages in your repository. When Composer looks for a package, it replaces `%package%` with the package name and fetches that URL. > > This means we've added a new endpoint `GET group/:id/-/packages/composer/p2/:package_name` which will return the metadata for all packages in your repository. > > Please note that there are two parameters considered optional. We have issues open to add support for the [`providers-api`](https://gitlab.com/gitlab-org/gitlab/-/issues/324706) and [`list-api`](https://gitlab.com/gitlab-org/gitlab/-/issues/324707) parameters. We hope to prioritize them in an upcoming milestone.

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[GitLab + Semgrep: upgrading SAST for the future](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> GitLab SAST historically has been powered by [over a dozen open-source static analysis security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month. Each of these analyzers is language-specific and has different technology approaches to scanning. These differences produce overhead for updating, managing, and maintaining [additional features](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#sast-analyzer-features) we build on top of these tools, and they create confusion for anyone attempting to debug. > > The GitLab Static Analysis team is continuously evaluating new security analyzers. We have been impressed by a relatively new tool from the development team at [r2c](https://r2c.dev) called [Semgrep](https://semgrep.dev/). It's a fast, open-source, static analysis tool for finding bugs and enforcing code standards. Semgrep's rules look like the code you are searching for; this means you can write your own rules without having to understand abstract syntax trees (ASTs) or wrestle with regexes. > > Semgrep's flexible rule syntax is ideal for streamlining GitLab's [Custom Rulesets](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) feature for extending and modifying detection rules, a popular request from GitLab SAST customers. Semgrep also has a growing open-source registry of 1,000+ [community rules](https://semgrep.dev/explore). > > We are in the process of transitioning many of our lint-based SAST analyzers to Semgrep. This transition will help increase stability, performance, rule coverage, and allow GitLab customers access to Semgrep's community rules and additional custom ruleset capabilities that we will be adding in the future. We have enjoyed working with the r2c team and we cannot wait to transition more of our analyzers to Semgrep. You can read more in our [transition epic](https://gitlab.com/groups/gitlab-org/-/epics/5245), or try out our first experimental Semgrep analyzers for [JavaScript, TypeScript, and Python](#experimental-semgrep-analyzer-for-python-javascript-and-typescript). > > We are excited about what this transition means for the future of GitLab SAST and the larger Semgrep community. GitLab will be contributing to the [Semgrep open-source project](https://github.com/returntocorp/semgrep) including additional rules to ensure coverage matches or exceeds our existing analyzers.

[Request a CVE ID from the GitLab UI](https://docs.gitlab.com/ee/user/application_security/cve_id_request.html#cve-id-requests): Vulnerability Database

> GitLab believes in responsibly disclosing software vulnerabilities. Since early 2020, GitLab has served as a [CVE Numbering Authority (CNA)](https://cve.mitre.org/cve/cna.html) and can provide [CVE IDs](https://cve.mitre.org/cve/identifiers/index.html) to security researchers and information technology vendors either for GitLab itself or for any project hosted on GitLab.com. > > With GitLab 13.11 we're making it easier for project maintainers to [request CVE IDs from GitLab via our UI](https://docs.gitlab.com/ee/user/application_security/cve_id_request.html#cve-id-requests). On confidential issues in public projects hosted on GitLab.com, maintainers will see the ability to request a CVE ID in the right-hand sidebar. Clicking the 'Request CVE ID' button in the issue sidebar takes you to the new issue page for the GitLab CVE project where you can complete the request template and trigger the request workflow. > > This feature can also be disabled on the project settings page should a project owner not want their repositories to offer this capability to maintainers. We are currently rolling out this feature slowly to GitLab.com hosted projects. You can follow our [rollout progress issue](https://gitlab.com/gitlab-org/gitlab/-/issues/299569) for updates or provide feedback.

[Support for Generic Kotlin SAST Scanning](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> Since 13.5, GitLab [Static Application Security Scanning (SAST)](https://docs.gitlab.com/ee/user/application_security/sast) has [supported scanning mobile projects](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps) including Android applications written in Kotlin. However, this Kotlin scanning only focused on mobile application security risks. In GitLab 13.11, thanks to a community contribution by [core team member](https://about.gitlab.com/community/core-team/) [Hannes Rosenögger (@haynes)](https://gitlab.com/haynes), our existing Java analyzer Spotbugs now supports scanning generic Kotlin projects and files. As [Kotlin](https://kotlinlang.org/) grows in popularity and slowly replaces Java in more modern projects, GitLab SAST continues to help developers ensure they are writing secure code.

[OpenShift Support for SAST and Secret Detection](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#sast-analyzer-features): SAST, Secret Detection

> Since 13.3, GitLab has [supported runners on Red Hat OpenShift](https://docs.gitlab.com/runner/install/openshift.html). Until now, GitLab Security scans did not support this deployment option. With 13.11, GitLab SAST and Secret Detection security analyzers can now operate within an OpenShift deployment. If you have overridden or provide a custom `.gitlab-ci.yml` file with pinned versions of SAST or Secret Detection analyzers please update to the [latest available versions](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). Please note that [experimental analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features) do not currently support OpenShift environments. As these analyzers are promoted from experimental status, [feature completeness](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#sast-analyzer-features) will be added.

[Static Analysis Analyzer Updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST, Secret Detection

> GitLab Static Analysis is comprised of a [set of 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. Below are the analyzer updates released during 13.11. These updates bring additional coverage, bug fixes, and improvements. > > - ESLint updated to version 7.23.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/merge_requests/75), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/blob/60510f6ad257ad5b73f1e002f14203e0551dbc99/CHANGELOG.md) > - MobSF updated to version 3.4.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/21), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/eed805ae68e059f51e467773100458d863496779/CHANGELOG.md#v280) > - njsscan updated to version 0.2.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/merge_requests/96/), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/blob/16e0371a78fcfdd9846d56b6d0496189826fa412/CHANGELOG.md#v2170) > - notable change: njsscan max file size has reduced from 25Mb to 5Mb. New Sequelize rules. > - gitleaks updated to version 0.2.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/109), [Changelog](https://github.com/zricethezav/gitleaks/releases/tag/v7.4.0) > - notable change: New PyPI and GitHub secret detection rules. > > If you are [including the GitLab managed vendored 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 do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations.

[Experimental Semgrep Analyzer for Python, JavaScript, and TypeScript](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> As part of [our partnership with Semgrep to power the future of GitLab SAST](#gitlab--semgrep-upgrading-sast-for-the-future), we are seeking beta testers to try our new Semgrep analyzer for Python, JavaScript, and TypeScript. These experimental analyzers run alongside our existing Python, JavaScript, and TypeScript analyzers such that you can compare vulnerabilities detected between the various analyzers. > > - Our new [Semgrep analyzer for Python](https://gitlab.com/groups/gitlab-org/-/epics/5688) will eventually replace our existing Python analyzer, Bandit. As part of this transition, our team has evaluated rule coverage for both tools to ensure that we maintain detection coverage. > - Our new [Semgrep analyzer for JavaScript and TypeScript](https://gitlab.com/groups/gitlab-org/-/epics/5440) will eventually replace our existing analyzer, ESLint. We currently are aware of a gap in detection coverage with ESLint that we are working with the Semgrep team to resolve. > > To run either of these analyzers, you'll need to [enable the experimental SAST flag](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features) within your 'gitlab-ci.yml' configuration file which will allow the new Semgrep analyzers to run alongside any existing SAST analyzers. Please note, currently, we have not completed remapping vulnerability findings between the analyzers, so you may see duplicated findings in your security report. This will be resolved before we complete this transition. We welcome any feedback or suggestions on these analyzers in the respective linked issues above.