GitLab.org/GitLab: Release v14.1.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.1
Released: 2021-07-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[External status checks for merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html):
> You can now contact an external API to perform a status check in a merge request. This is a great way to integrate GitLab with third-party systems that:
>
> - Run in an external system and do not have specific pipeline jobs.
> - Require manual approval in another system.
>
> In the project, APIs for the status checks can be configured (using either the GitLab UI or the GitLab API) and then when a change is made to a merge request, that API is called with various details about the merge request. The external API can then respond with a return code to indicate if the check has passed. This result is then shown in the merge request.
>
> This allows teams to easily stay in sync and makes it easy to see that merge requests have met external requirements before being merged, adding an extra method to ensure compliance requirements are met.
Compliance Management[Quick access to compliance report entries](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/#merge-request-drawer):
> We have introduced a new quick access view to the Compliance Dashboard for you to review merge requests.
> Clicking on a merge request in the list will open the view. This makes it easy to quickly
> see the status and the details of merge requests, directly inside
> the Compliance Dashboard.
>
> This helps save time by showing information about each merge request, such as the author, title, approvers,
> commenters, and more. You no longer have to open each merge request individually
> to see that information. Compliance teams can quickly review the full list of merge requests and find the ones that need attention, rather than spending time reviewing ones that do not.
Compliance Management[Require a Jira issue to be linked to an MR](https://docs.gitlab.com/ee/integration/jira/issues.html#require-associated-jira-issue-for-merge-requests-to-be-merged):
> You can now require that all merge requests in a project have an associated Jira issue created. This is a great way to ensure that code changes in GitLab are reflected in Jira issues and that teams can better stay in sync.
Compliance Management[Track progress on overall DevOps adoption](https://docs.gitlab.com/ee/user/group/devops_adoption/):
> See the total number of key DevOps features adopted across your organization using the new progress bars in DevOps Adoption. Progress bars help you understand the value that teams are getting from GitLab and evaluate the state of your DevOps transformation.
DevOps Reports[Track use of security scanning across multiple teams](https://docs.gitlab.com/ee/user/group/devops_adoption):
> Track which groups across your organization have enabled SAST and DAST scanning. This is helpful for verifying compliance with organizational requirements, responding to audit requests, and tracking progress on company initiatives to make applications more secure. To track adoption, go to the **Sec** tab in DevOps Adoption either at the group level or instance level.
>
> To see groups that have enabled fuzz testing and dependency scanning, use [the DevOps API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#devopsadoptionsnapshot). Fuzz testing and dependency scanning will be added to the DevOps Adoption UI in an upcoming release.
DevOps Reports[Inline code quality notices on MR diffs](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-in-diff-view):
> If you're a developer authoring or reviewing a merge request, you want to know how every change
> impacts the quality of a project. To do this within GitLab, you previously needed
> two windows open:
>
> 1. On the code diff of the merge request.
> 2. On the main merge request page to see the code quality changes.
>
> This back-and-forth is inefficient, and makes it easy to miss critical code quality issues.
>
> The merge request **Changes** tab now shows you which line introduced a code quality violation, and its severity, so you can quickly identify the most critical issues to resolve. Hovering over the icon provides details about the violation.
Code Quality[DAST UI configuration experience](https://docs.gitlab.com/ee/user/application_security/dast/#configure-dast-using-the-ui):
> GitLab’s Dynamic Application Security Testing (DAST) now supports a new guided configuration experience. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab DAST. The tool helps a user create a merge request to enable DAST scanning while leveraging best configuration practices like using the GitLab-managed `DAST.gitlab-ci.yml` template and properly overriding template settings.
>
> With GitLab DAST, users often create multiple configurations to cover different areas of their application. The new DAST configuration UI lets users create DAST site and scanner profiles. Those profiles can then be referenced in CI/CD pipeline jobs. The configuration is stored in the database and is referenced at scan runtime to load the configuration variables into the job. The only required YAML configuration is specifying the names of the site and scanner profiles that you want to use in your scan. This makes it incredibly simple to switch out configurations when your application requires. Building YAML config files for DAST from scratch is no longer necessary for your DAST jobs. We can build them for you.
DAST[Beta release of DAST API Security scanner](https://docs.gitlab.com/ee/user/application_security/dast_api/):
> In 2020, GitLab acquired Peach Tech and gained an incredibly powerful DAST API Security tool in the process. After initially focusing on the fuzz testing capabilities of the tools we acquired, we are proud to announce that the API Security scanner for DAST is now ready for use as a beta feature. This scanner immediately gives the benefit of enabling more API specification methods, more API language support, and additional authentication methods. In addition to the already supported OpenAPI specification, you can now use Postman collections and HAR files to provide multiple options for defining what can be tested in the API. In addition to supporting REST APIs, the new beta API Security scanner also supports SOAP and GraphQL API endpoints. Additional authentication methods include static cookies, form bodies, JSON bodies, and XML bodies. Dynamic headers, cookies, query strings, form bodies, JSON bodies, and XML bodies are also now supported via user-provided scripts that update the values.
>
> As a part of this beta, the DAST API job for the API Security scanner is now separate from the traditional web application DAST job in your CI/CD pipeline. The DAST API job can be configured separately, using new variables and a new DAST API YAML template. This is a major improvement that enables usage of both web application DAST and API DAST in the same pipeline. You no longer have to choose between one type of DAST scan or the other when testing your applications. One pipeline can provide dynamic application security test coverage of both the UI and API of an application.
>
> While this new scanner gives us a major improvement in functionality, we have identified that there are multiple vulnerability checks that need to be implemented in order to provide vulnerability coverage parity with the current DAST API scanner. We will continue to work on building those vulnerability checks to get the API Security scanner to a GA maturity. During the beta period, we strongly encourage usage of the new scanner and welcome any feedback.
DAST[Browser-based DAST authentication](https://docs.gitlab.com/ee/user/application_security/dast/#authentication):
> As a part of our project to move to a browser-based DAST ecosystem, we have switched the DAST authentication method over to using browser-based authentication. In addition to supporting all of the existing DAST methods of authentication, this new system allows for advanced debugging by generating a report that contains screenshots and HTTP requests made during the authentication process. The report allows a user to view all the steps in the process and see what is happening if authentication fails. The new authentication method also contains quality-of-life improvements such as greater flexibility for how to select login form elements on a page, support for clicking elements to show a popup login modal, strategies for validating whether or not authentication succeeded, and direct access to the browser logs for debugging purposes.
DAST[Enable Dependency Scanning within the UI](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration):
> Users with access to the Security Configuration page who do not yet have Dependency Scanning enabled can now enable it by clicking "Configure via Merge Request". This will create and/or update your pipeline YAML file to add the default Dependency Scanning template. This will make it easier for you to quickly add Dependency Scanning into your project providing an additional layer of security to your standard development workflow.
Dependency Scanning[Configuration tool for Secret Detection available to all](https://docs.gitlab.com/ee/user/application_security/configuration/) (SaaS only):
> Following in the footsteps of the [GitLab SAST configuration tool](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui) we added support for Secret Detection on the Security Configuration page in 13.12. We believe that [security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort) and this configuration experience makes it easier for non-CI experts to get started with [GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) which is why we're making this tool available for all SaaS users in 14.1, and all self-managed users soon. The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). The Configuration tool can create a new `.gitlab-ci.yml` file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI set up.
Secret Detection[Dependency Scanning expands support for Gradle projects](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning):
> You can now enable Dependency Scanning for your Java 16 Gradle projects. Set the `DS_JAVA_VERSION` environment variable to `16` to use this enhancement. In addition the gemnasium-gradle-plugin has been updated to support Gradle 7.0. [Gradle 7.0 issue](https://gitlab.com/gitlab-org/gitlab/-/issues/329805).
Dependency Scanning[Support for UBI-Based Container Scanning Image](https://docs.gitlab.com/ee/user/application_security/container_scanning/#ubi-based-images):
> GitLab now supports a [Universal Baseline Image](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image) (UBI) version of the container scanning image. By default, GitLab container scanning runs on an Alpine-based image. However, you may prefer or require it to run on a UBI-based image instead. You can now choose to have your container scanning jobs run on a UBI-based image by following [these steps](https://docs.gitlab.com/ee/user/application_security/container_scanning/#ubi-based-images).
Container Scanning[CI/CD Tunnel for Kubernetes clusters](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_tunnel.html):
> Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab. Some organizations do not encourage opening up their firewall externally due to security concerns.
>
> GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the [GitLab Agent](https://docs.gitlab.com/ee/user/clusters/agent/). This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.
>
> You and your team can safely use your preferred tool to run the deployment itself using `kubectl`, `helm`, `kpt`, `tanka`, or anything else without security concerns.
>
> To use the tunnel, define the `kubecontext` in your CI/CD pipeline to connect with your agent. To simplify this process, we plan to [automatically inject the `kubecontext`](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) into the CI/CD environment in a future iteration.
>
> The CI/CD tunnel is currently supported only from the project where the agent was configured but we are working on [adding group-level support](https://gitlab.com/groups/gitlab-org/-/epics/5784). You can safely start using the tunnel on GitLab SaaS and self-managed instances.
Kubernetes Management[Vault integration with environment variables support](https://docs.gitlab.com/ee/ci/yaml/#secretsfile):
> Vault users can easily retrieve secrets from within GitLab CI/CD by using the GitLab Vault integration. The integration initially created `file` type secret variables, and this approach had a few shortcomings. To overcome these we are introducing a new boolean `file` keyword where you can specify if the returned variable should be stored as a plain environment variable or a file.
>
> This feature requires a GitLab Runner version 14.1.0. For backward compatibility, the default is to store the variables as file types (`file: true`).
Secrets Management[Audit events for project compliance frameworks changes](https://docs.gitlab.com/ee/administration/audit_events.html#project-events):
> Audit events are now being created when the [compliance framework](https://docs.gitlab.com/ee/user/project/settings/#compliance-frameworks) for a project is changed. This provides greater visibility into potential abuse of policy controls of your projects.
Audit Events[Audit events for API-created GPG and SSH keys](https://docs.gitlab.com/ee/administration/audit_events.html#instance-events):
> Audit events are now created if a [GPG key](https://docs.gitlab.com/ee/api/users.html#add-a-gpg-key) or [SSH key](https://docs.gitlab.com/ee/api/users.html#add-ssh-key) is created using the API. This extends visibility beyond users that create keys using the GitLab UI to help you understand and secure all the ways GitLab could be accessed.
Audit Events[Audit events for new instance administrators](https://docs.gitlab.com/ee/administration/audit_events.html#instance-events) (self-managed only):
> Audit events are now created if a user is added as an administrator for the GitLab instance. This helps ensure that if anyone becomes an administrator (meaning they make changes to instances), there is a record of their permissions being elevated that can be audited later.
Audit Events[Related feature flags in issues](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-related-issues):
> In GitLab 13.2, we added the ability to associate issues to feature flags. In this release, we added the ability to associate feature flags with issues. An issue often has the context for the 'why'. Allowing a user to be able to navigate from issue to feature flag, and back again will enable the user to have the complete context on what the feature flag is for.
Feature Flags[Code coverage merge request approval rule](https://docs.gitlab.com/ee/ci/pipelines/settings.html#coverage-check-approval-rule):
> To keep code test coverage high, you need to ensure that merge requests to your codebase never decrease test coverage. Previously, the only way to enforce this was to [require approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/#required-approvals) from users who would check for test coverage decreases as part of their reviews.
>
> Now you can enforce this organizational policy with the new Coverage check approval rule. This is a simple way to ensure merge requests that would decrease test coverage cannot be merged.
Code Testing and Coverage[Escalation Policies](https://docs.gitlab.com/ee/operations/incident_management/escalation_policies.html):
> Being on-call is a stressful, 24/7 job. It's possible to miss a notification despite your best efforts and intentions. Teams that maintain critical systems can't afford to miss alerts for outages or service disruptions. Escalation policies are a safety net for these situations. Escalation policies contain time-boxed steps that automatically page a responder in the next escalation step if the responder in the step before didn't respond. To protect your company from missed critical alerts, create an escalation policy in the GitLab project where you manage on-call schedules.
>
> In GitLab 14.1, users can create, view, or delete escalation policies.
Incident Management, On-call Schedule Management[Datadog CI Visibility integration](https://docs.gitlab.com/ee/integration/datadog.html):
> The integration with [Datadog Continuous Integration Visibility](https://docs.datadoghq.com/continuous_integration/) provides detailed breakdowns of your GitLab pipelines, unit tests, and integration tests. View high-level metrics over time: execution statuses, durations, percentiles (p50 and p95), failure rates, queue times, and more. Datadog dashboards help you sift through your GitLab CI/CD data to identify problematic jobs that cause pipelines to fail most often.
Integrations[Select project access token role](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) (self-managed only):
> Users can now specify the level of access that a project token should have on the project level upon creation and can view existing project access token roles.
>
> Prior to this release, project access tokens had the [Maintainer](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions) role. For some users, this role included elevated permissions that were not required.
>
> To avoid abuse, this feature is available for all users except for free GitLab SaaS accounts. All self-managed users as well as Premium and Gold SaaS customers can now easily select and view the appropriate role for their project access tokens.
Authentication and Authorization[User setting to display absolute times](https://docs.gitlab.com/ee/user/profile/preferences.html#time-preferences):
> GitLab displays relative times (for example, 30 minutes ago) in a lot of places. You can now change your user profile preferences to display absolute times instead, for example, 'May 18, 2021, 3:57 PM'.
>
> Absolute times respect your browser settings and format dates and times based on your preferred locales, for example, British English over US English. This new display option gives more information at a glance for users that need it for workflows like correlating actions in GitLab to external systems.
Internationalization[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - GitLab 14.1 replaces `tail`/`xtail` in favor of [GitLab Logger](https://github.com/jbguerraz/gitlab-logger) in Gitaly cloud native GitLab Containers. In the past, logs were less structured which made it potentially more challenging to do proper analysis. [Using GitLab Logger](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2433) allows better tagging of logs to improve forensic analysis.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab 14.1 includes [Mattermost 5.36](https://mattermost.com/blog/mattermost-release-v5-36/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes the addition of Hungarian language support, a Focalboard project management integration (beta), and more. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrading from earlier versions is recommended.
> - GitLab 14.1 also introduces the [ability to opt-in to PostgreSQL 13](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5507) for fresh single-node installations not using Geo or a multi-node setup. This prompt allows users to benefit from the features and functions associated with the latest version of PostgreSQL.
> - GitLab users expressed a need for more modern practices related to NGINX TLS configuration in GitLab instances. In 14.1, the SSL configuration is updated to use the [intermediate setting from Mozilla's SSL configurator](https://ssl-config.mozilla.org/#server=nginx&version=1.14.2&config=intermediate&openssl=1.1.1d&ocsp=false&guideline=5.6).
Omnibus Package[Registration Features](https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program) (self-managed only):
> [Registration Features](https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program) introduces the ability for free, self-managed users running GitLab EE to access paid features by registering with GitLab and sharing activity data via [Service Ping](https://docs.gitlab.com/ee/development/service_ping/index.html#what-is-service-ping). Features introduced here do not remove the feature from it's paid tier, or prevent users from accessing at that tier without sharing usage data. The first feature introduced is [email from GitLab](https://docs.gitlab.com/ee/tools/email.html), enabling instance administrators to email users within their instance.
Product Analytics[Pronouns viewable in user profile snapshot](https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns):
> You can now see pronouns on the snapshot view of a user profile when you hover over someone's name on an issue or merge request. This helps users better respond to comments using the correct pronouns without needing to navigate to the user's profile.
Users[Log the number of objects imported from GitHub](https://docs.gitlab.com/ee/development/github_importer.html#logs):
> When you import from GitHub, the logs now contain the counts of all imported objects. This information helps users validate their imported data and troubleshoot any import issues.
Importers[Group Migration now includes Epics](https://docs.gitlab.com/ee/user/group/import/):
> The new GitLab [Group Migration](https://docs.gitlab.com/ee/user/group/import/) feature now includes Epics with all the relevant information, such as labels, comments, events, and award emojis. Existing users are matched and assigned to the Epics. The addition of Epics is a significant step in delivering a better alternative to the file-based [Group Export/Import](https://docs.gitlab.com/ee/user/group/settings/import_export.html) feature.
Importers[LDAP synchronization warning before external users lose access](https://docs.gitlab.com/ee/user/group/#manage-group-memberships-via-ldap):
> Users are now shown a warning if they choose to synchronize their groups with LDAP. Once groups are synchronized with LDAP, all users that are external to the LDAP group lose their access. This ensures that the user is aware of the impact of synchronization and gets a confirmation before the synchronization takes place.
Authentication and Authorization[Email notification when users are deactivated](https://docs.gitlab.com/ee/administration/moderate_users.html#activating-and-deactivating-users):
> Users now receive a notification when they are deactivated. This informs users so they can:
>
> - Take action to reactivate their account.
> - Understand why they are no longer receiving any notifications from GitLab.
> - Understand why they can't access GitLab APIs and repositories.
Users[Disable jailing mechanism by default for GitLab Pages](https://docs.gitlab.com/ee/administration/pages/#jailing-mechanism-disabled-by-default-for-api-based-configuration):
> We are now disabling the [jailing](https://www.thegeekdiary.com/understanding-chroot-jail/) mechanism for GitLab Pages by default due to [problems discovered when upgrading to GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/331699). Jailing is no longer relevant since we stopped serving GitLab Pages directly from disk starting in 14.0. You can still [re-enable jailing](https://docs.gitlab.com/ee/administration/pages/#jailing-mechanism-disabled-by-default-for-api-based-configuration) if you require the functionality though. In that case, please reach out to us on the [Pages migration feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/331699), so that we can investigate your case.
Pages[Fix create/edit/delete release permissions to match tag creation permissions](https://docs.gitlab.com/ee/user/project/releases/#release-permissions):
> In GitLab 14.1, we are fixing the create/edit/delete release permissions to match tag creation permissions so that users have a consistent experience. This bug fix is highlighted individually because for projects that have releases associated with a protected tag, the user must have write access to both releases and protected tags in order to access the release. If this bug fix affects you, add the pertinent user to the **Allowed to create** list in [the protected tag setting](https://docs.gitlab.com/ee/user/project/protected_tags.html#configuring-protected-tags).
Release Orchestration[Create tables and upload images in the Wiki Content Editor](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor):
> We began improving your wiki editing experience in GitLab 14.0, when we introduced the MVC of a new WYSIWYG Markdown editor. It supported the most common Markdown formatting options, but with some notable gaps. GitLab 14.1 continues to improve your editing experience for images and tables. You can now upload images directly into the editor. You can also insert and edit tables, including copying and pasting content from popular spreadsheet applications to bring tables from other sources into your wiki.
Wiki[Comments indicator for merge request reviews in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#merge-request-reviews):
> When responding to feedback on a merge request in Visual Studio Code, it wasn't easy to know which files had comments. You had to open each file and search for comments.
>
> With [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) [v3.24.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3240-2021-06-30) for VS Code, we now indicate which files have comments in the merge request. This helps you easily identify the files you may need to review, to address their comments.
Editor Extension[Check out branches of merge requests in Visual Studio Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#merge-request-reviews):
> When reviewing a merge request (MR) in Visual Studio Code it can be helpful to check out the branch proposing the changes. Finding the source branch's name and then switching context to check it out can be challenging.
>
> Now when [reviewing an MR](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#merge-request-reviews) with [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for Visual Studio Code you can right click the MR title to check out its source branch. This makes it easier to review the proposed changes in the larger context, test items locally, and perform other actions on the source branch.
Editor Extension[Create and apply patches in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#create-and-apply-snippet-patch):
> When reviewing a merge request (MR) it can be helpful to make suggestions to many of the changed files. This is often done by creating a patch file with the suggestions and sharing it with others. The problem is that this requires several manual steps like running Git commands and uploading the patch file somewhere others can download it.
>
> With [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) [v3.26.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3260-2021-07-13) for VS Code you can now create and apply patches directly in your editor. The new `GitLab: Create snippet patch` command creates a patch with the changes in your editor and uploads that patch as a [GitLab snippet](https://docs.gitlab.com/ee/user/snippets.html).
>
> Anyone can search for patches in the project's snippets and apply them directly in VS Code with the `GitLab: Apply snippet patch` command. The applied changes can then be committed to the MR.
>
> Sharing and collaborating around patches is a great way to propose more complex suggestions and provide clear improvements. Patches created in VS Code can also be linked to others through snippets and downloaded and applied outside of VS Code for users with different editing tools.
Editor Extension[Default branch name redirect](https://docs.gitlab.com/ee/user/project/repository/branches/default.html#default-branch-rename-redirect):
> As part of the larger effort to rename Git's default initial branch in a GitLab project from `master` to `main`, we are adding an automatic redirect to streamline the transition. Previously, when projects renamed the default branch, current URLs would result in `404 Not Found`. This is a frustrating experience when you are trying to navigate between branches. Now, if you navigate to a file or directory path whose default branch was renamed, you will be redirected to the updated path automatically.
Source Code Management[GitHub-formatted anchor links highlight correctly](https://docs.gitlab.com/ee/development/):
> Linking directly to a single, highlighted line of code or text supports collaboration on a single line, but discussions often address multiple lines of code or text. Some code editor plugins, such as [GitLink](https://plugins.jetbrains.com/plugin/8183-gitlink) for JetBrains IDEs, generate an anchor link from a selected range over multiple lines. Previously, you couldn't use such links in GitLab repositories, because GitLab and GitHub have incompatible formats for anchor links highlighting multiple lines. Previously, only manually modifying the incompatible URL in GitLab enabled highlighting multiple lines. GitLab now supports both GitLab and GitHub formats for code highlight anchor links that cover multiple lines.
Source Code Management[New content types in the Wiki Content Editor](https://docs.gitlab.com/ee/user/project/wiki/#content-editor):
> In GitLab 14.0, we introduced the Content Editor in the Wiki, a new WYSIWYG Markdown editor with support for basic content types like **bold**, _italic_, `code`, block quotes, and links. In 14.1, we're adding the ability to format text with strikethrough and insert [horizontal rules](https://gitlab.com/gitlab-org/gitlab/-/issues/328627). Adding these frequently-used content types brings us closer to our goal of giving all users a rich editing experience without learning Markdown, with [full support for the GitLab Flavored Markdown specification](https://gitlab.com/groups/gitlab-org/-/epics/5438), to make this the default editing experience for the Wiki.
Wiki[Display CSV files in readable table view](https://docs.gitlab.com/ee/user/project/repository/csv.html):
> Data in CSV (comma-separated value) files is easier to understand when shown as a table with columns and rows, especially if the file is large. Previously, CSV information was presented as raw text in GitLab repositories. CSVs are now represented as a table, with the RAW view representing the actual comma separated values.
Source Code Management, MLOps[Visibility into CI minute tracking and quotas for public projects](https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes):
> It was really challenging to get a complete picture of your CI minute consumption because public projects were excluded from quotas. As a result, we have improved the [pipeline usage](https://docs.gitlab.com/ee/ci/pipelines/#pipeline-quotas) page to show public project CI minute consumption. Including public projects in the CI minute quota enables you to get a complete picture of your usage to make informed decisions about your pipeline efficiency. These quotas are also supporting our efforts to [curtail crypto-mining abuse](https://about.gitlab.com/blog/2021/05/17/prevent-crypto-mining-abuse/).
>
> Additionally, we are starting to implement quotas for the use of our public shared runners by pipelines in public projects. Initially, quotas for public projects will apply to all *new* namespaces created after July 17th. All plans will have a quota, and for new users on the Free plan, public projects will have 50,000 minutes of shared runner use available for their jobs.
Continuous Integration (CI)[Access the CI/CD template library from the pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/):
> Templates provide an easy way for you to get familiar with GitLab CI/CD. We have a large number of templates, but accessing them isn't intuitive. In this release we've added a way for you to navigate directly to the template library from the pipeline editor. This makes it easy to browse through the different templates GitLab has available, so you can more easily copy and paste the relevant sections directly into your pipeline configuration.
Pipeline Authoring[Updates to Admin Area's Runners page](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners):
> Today, you can administer all runners in a GitLab instance from the [Admin Area's Runners page](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners). However, the capabilities on this page are not helpful for GitLab administrators who are managing and operating a large fleet of runners. In this first of many planned [iterations](https://gitlab.com/groups/gitlab-org/-/epics/5665), the Admin Area's Runners page now uses Vue.js and GraphQL. In this release, you will notice that the list and detail views are now consistent with other areas of the GitLab UI. This new architecture enables us to have a more interactive UI, iterate more quickly, and add new features and capabilities to help you administer and operate runners at scale.
GitLab Runner[Limit runner registration for groups and projects](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#runner-registration):
> Today, you can register runners at the group and project levels in a GitLab instance by default. For some organizations with more stringent security controls, administrators need to limit the registration of project and group runners. This community contribution adds two configuration options in the Admin Area so that you can turn off the runner registration options at the project and group level. To test this feature, you will need to enable [the `:runner_registration_control` feature flag](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#runner-registration).
>
> Thanks to [Thomas Watts](https://gitlab.com/discinaround) for their contribution!
GitLab Runner[Runner registration tokens in the Admin Area are masked](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#runner-registration):
> The instance-level runner registration token is sensitive information. If someone were to "shoulder surf" a GitLab administrator, they could copy the instance-level registration token and use it to add unauthorized runners and read secrets from the GitLab instance when runners process jobs. We have masked the token so it is only left visible on the screen when intended.
GitLab Runner[Enable GraphQL Runner API by default](https://docs.gitlab.com/ee/api/graphql/reference/#queryrunner):
> Previously, to manage runners programmatically, you had to fetch and manipulate data by using a REST API. As part of our plans to improve the administration of runners, we are implementing GraphQL as one foundational element in delivering a better user experience in the runner's Admin Area UI. With this release, you can now use GraphQL queries and mutations to administer runners for your GitLab instance programmatically.
GitLab Runner[GitLab Runner 14.1](https://docs.gitlab.com/runner/):
> We're also releasing GitLab Runner 14.1 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:
>
> - [Add support for Windows Server, version 20H2 (Semi-Annual Channel)](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27220).
> - [Pass the job payload to the GitLab Runner custom executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4677).
> - [Stop considering Docker image pull as runner system failure](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27880).
>
> #### Bug Fixes:
>
> - [Docker jobs fail with exit code 137](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28001).
> - [Fix trace short writes for large log lines](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2993).
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-1-stable/CHANGELOG.md).
GitLab Runner[Work from branches in the Pipeline Editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html):
> Previously, you could only use the pipeline editor to work on your pipeline configuration in your project's default branch. In this release, we are adding a branch selector to the pipeline editor. Now you can use the pipeline editor from any branch you'd like, which makes it much easier to test changes before implementing them on the default branch.
Pipeline Authoring[Build, publish, and share Helm charts](https://docs.gitlab.com/ee/user/packages/helm_repository/):
> Helm defines a [chart](https://helm.sh/docs/intro/using_helm/#three-big-concepts) as a Helm package that contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. For organizations that create and manage their own Helm charts, it's important to have a central repository to collect and share them.
>
> GitLab already supports a variety of other [package manager formats](https://docs.gitlab.com/ee/user/packages/). Why not also support Helm? That's what community member and [MVP from the 14.0 milestone](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#mvp) [Mathieu Parent](https://gitlab.com/sathieu) asked several months ago before breaking ground on the new GitLab Helm chart registry. The collaboration between the community and GitLab is part of our [dual flywheel strategy](https://about.gitlab.com/company/strategy/#dual-flywheels) and one of the reasons I love working at GitLab. Chapeau Mathieu!
>
> Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that's done you can use the Helm client or GitLab CI/CD to manage your Helm charts. You can also download the charts using the [API](https://docs.gitlab.com/ee/api/packages.html#get-a-project-package) or the [user interface](https://docs.gitlab.com/ee/user/packages/package_registry/#download-a-package).
>
> What's next? First, we'd like to [present additional metadata for charts](https://gitlab.com/groups/gitlab-org/-/epics/6399). Then we'll start [dogfooding](https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything) the feature by using it as a replacement for Helm Chart Registry[The Package Registry now supports NuGet symbol packages](https://docs.gitlab.com/ee/user/packages/nuget_repository/#symbol-packages):
> You can use the GitLab Package Registry to publish and install NuGet packages right alongside your source code and pipelines. Since packages are collections of code, sometimes they have bugs. So how do you debug NuGet? One common way is to use debug symbols that provide information like the association between compiled and source code, names of local variables, stack traces, and more.
>
> The problem is that although GitLab supports NuGet packages, until recently symbol packages (`.snupkg`) weren't supported. This made it more difficult to share these important debugging packages with the rest of your team and prevented you from relying on GitLab as the single source of truth for your NuGet packages.
>
> GitLab now supports publishing and installing symbol packages. To publish a symbol package, simply run `nuget push My.Package.snupkg -Source Package Registry[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> 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 14.1. These updates bring additional coverage, bug fixes, and improvements.
>
> - Flawfinder updated to version 2.0.18 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/merge_requests/62/), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/blob/master/CHANGELOG.md#v2142).
> - Gosec updated to version 2.8.1 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/merge_requests/119), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/5dcc1a4775a8f3b2f12af59ce9d9977eeb4aab4f/CHANGELOG.md#v311).
> - Semgrep updated to version 0.57.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/67/diffs), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md):
> - Set a timeout of 10s per file.
> - Fixed bugs in detection patterns.
> - New detection patterns.
> - MobSF updated to version 2.13.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/34), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v2130):
> - Removes support for Python 3.8 to mitigate security issue.
>
> 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/CD template, you will need to update your CI/CD configurations. If you want to remain on a specific version of any analyzer, you can now [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 will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI/CD template.
SAST, Secret Detection