GitLab 15.7 released introducing the GitLab CLI and with browser-based DAST GA
We are excited to announce the release of GitLab 15.7, which introduces the new GitLab CLI, general availability of browser-based DAST, support for GitOps deployments from outside the default branch, and much more!
These are just a few highlights from the 70+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 190+ contributions they provided to GitLab 15.7! At GitLab, everyone can contribute and we couldn't have done it without you!
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.8 release kickoff video.
This month's Most Valuable Person (MVP) is Niklas van Schrick
Niklas has continually iterated on a manual, painful process for the Technical Writing (TW) team until ultimately making that process simple and automated.
Niklas worked to refine how to run batch updates to the CODEOWNERS file and the related issues. Read the full story of Niklas’s impact.
Additionally, Niklas is playing a fundamental role in building GitLab’s achievement system and has had at least one MR merged every milestone since 14.3!
Introducing the GitLab CLI
The command line is one of the most important tools in a software engineer’s toolkit and the majority of their process and work revolve around tools available there. They customize their CLI with styles and extend it through applications to ensure maximum efficiency while performing tasks. The CLI is the backbone of scripts and workflows developers depend on to complete their work.
To support more developers where they’re already working, we’ve adopted the open source project glab, which will form the foundation of GitLab’s native CLI experience. The GitLab CLI brings GitLab together with Git and your code, with no application or tab switching required.
You can read about our adoption of glab, our partnership with 1Password, and how to contribute to the project in our blog post.
A special thank you to Clement Sam for creating glab and trusting us with its future.
Share CI/CD access to the agent within a personal namespace
The GitLab agent for Kubernetes provides a more secure solution for managing your clusters with GitLab CI/CD. You can use a single agent with multiple projects and groups by sharing access to the agent connection. In previous releases, you could not share access with personal namespaces. This release adds support for CI/CD connection sharing to personal namespaces. You can now use a single agent from any of the projects under your personal namespace.
Support GitOps deployments from outside the default branch
In previous releases, the GitLab agent for Kubernetes was restricted to manifest files stored on your main branch. This model had known limitations. For example, you couldn’t store the manifests of your next release on a release branch and test them in an ephemeral environment.
Now, you can specify a Git reference along with the manifest project configuration. Besides the main branch, you can sync your manifest files from another branch, a git tag, or a specific commit.
Sign commits with your SSH key
Signing commits just got a lot simpler. Use SSH keys to sign commits, and provide others with confidence that a Verified commit was authored by you.
Previous methods for signing commits required a GPG key or an X.509 certificate, neither of which can be used to sign in to GitLab. Adding support for commit signing with SSH keys now makes it possible to reuse your authentication key pair to also sign your commits. If you already authenticate into GitLab with an SSH key, add three lines of code to your local Git configuration and all your future commits will be signed.
By default, all SSH keys currently in your profile can be used for both authentication and signing commits. To use a key for only one of the purposes, upload a new key.
Experience the Web IDE Beta and Remote Development
We are thrilled to announce the availability of the Web IDE Beta, our next-generation web editor based on Visual Studio Code that delivers powerful new features, a more flexible and familiar interface, and the ability to connect directly to a Remote Development environment. Paired with a cloud runtime, the Web IDE Beta enables more advanced real-time development workflows. Take a look at just some of the new features available today!
The Web IDE Beta is so powerful we’re making it the default Web IDE experience for GitLab.com, and we’re eager for your feedback. The Web IDE will continue to be available while we iterate on the Beta. To stop using the Web IDE Beta, go to your user preferences and select the Opt out of the Web IDE Beta checkbox.
Self-managed instances have access to the Web IDE Beta where it is behind a feature flag disabled by default in GitLab 15.7.
Learn more about the Web IDE Beta and what’s coming next in our recent blog post.
Self-managed support for the GitLab for Jira Cloud app
For self-managed GitLab, we’re excited to announce support for the GitLab for Jira Cloud app!
With this release, you can link your self-managed GitLab instance to Jira Cloud and enable the Jira development panel. This feature supports syncing updates from smart commits, merge requests, branches, builds, deploys, and feature flags back into the Jira development panel. You can pair the GitLab for Jira Cloud app with your basic Jira integration.
For more information, see Connect the GitLab for Jira Cloud app for self-managed instances.
If you use Jira Server or Jira Data Center, you should use the Jira DVCS Connector.
Retry a manual job with updated variables
When running manual jobs, users can specify the extra CI/CD variables to use in the job. However, if you wanted to retry the same job, you always had to use the same variables as the first time. If you wanted to run the job with different variables, you had to run a new pipeline.
In this release, we have added the ability to specify variables every time you run a manual job, including when retrying the job. This allows for greater flexibility and convenience as you can retry a manual job as often as you like with a different set of variables in every run.
Browser-based DAST general availability
After being available in Beta since GitLab 13.2, our proprietary browser-based DAST analyzer is now being released for general availability in GitLab 15.7.
This new analyzer has been developed completely in-house and makes use of a browser to authenticate, crawl, and scan web applications for vulnerabilities. Traditional DAST analyzers scan using a proxy-based approach to intercept requests and analyze them for vulnerabilities. Because of this, running DAST scans on applications that utilize modern JavaScript frameworks or are single page applications has been extremely difficult. Often, you do not get the full coverage of the application that you would expect. With the browser-based approach, we are able to execute JavaScript directly in the browser, as a user would, to ensure that your entire application is scanned for vulnerabilities. Using the new analyzer, we are able to cover more of the pages in an application, as well as reduce the number of false positives reported.
At this time, we will not be switching the default analyzer used in the DAST.gitlab-ci.yml template to the browser-based analyzer, to allow users to make the switch manually and evaluate it for themselves. However, we plan to make the analyzer the default for all DAST scans at some point in the future. We encourage everyone to start to migrate to the new analyzer, so that when the default switch happens, it will not break any of your DAST scans. You can enable the browser-based analyzer by setting the DAST_BROWSER_SCAN to true in your .gitlab-ci.yml configuration. Please note that not all legacy DAST analyzer variables will be used with this new analyzer. Any unsupported legacy DAST variables configured in your .gitlab-ci.yml file will be ignored during the scan run.
We will continue to improve on this analyzer and have plans for many new features that the browser-based approach opens up to us. You can see our plans by looking at our browser-based DAST epic and its issues. We would love to get feedback on this epic (or any child issues) about what is most important for you in your DAST scans.
Select predefined CI/CD variables values from a dropdown list
Previously, you could pre-fill CI/CD variables in the “Run pipeline” page, with a specific value. Unfortunately, if you had multiple options for the variable’s value, you still had to manually input the option you wanted. This was an error-prone process because you could easily input an invalid value, or just mistype it.
In this release, we’ve added the ability to set a list of values which are surfaced in a drop-down list in the “Run pipeline” page. Now you can define the exact list of values that are valid for each CI/CD variable when running a pipeline manually, greatly simplifying your workflow when using manually-triggered pipelines.
Support the $ character in CI/CD variables
Previously, using the $ character in a CI/CD variable always indicated the start of a reference another variable, which GitLab then tried to expand. As a result, you could not have a value with a $ as part of the string unless it was escaped, which can be confusing.
In this release, we are introducing a new setting for project, group, and instance CI/CD variables. You can now toggle whether or not GitLab interprets the CI/CD variable as a raw string, or treats a $ as the start of another variable that should be expanded.
Audit event recorded when Admin Mode enabled
GitLab now records an audit event when an administrator enables Admin Mode. This is helpful for security-related auditing, because Admin Mode allows the user to elevate permissions and change instance level settings.
Cancel import of a project from GitHub
When importing GitHub projects into GitLab, you could not cancel an import that was in progress.
You can now cancel imports from GitHub that are pending or in progress. If the import has already started, the imported files are kept.
Group owners can list user’s email addresses using the API
Group owners can now use the API to access the email addresses of any user provisioned by the group. A user is provisioned by the group when their account was created by SCIM, or by first sign in with SAML SSO for GitLab.com groups. Previously, group owners could only access this information if a user’s email addresses were public.
Option for single sign-on users to stay signed in
Users signed in to GitLab with single sign-on were signed out frequently. Now, these users can select the Remember me checkbox and stay signed in to GitLab for two weeks. When accessing group resources, users are redirected to their Identity Provider (IdP) once every 24 hours to verify the session. Depending on their IdP’s settings, users may have to re-authenticate to the IdP at this time.
Webhook push events support regular expressions
For webhooks triggered on push events, you can now define a regex pattern that aligns with your branching strategy. For example, you can use ^(feature|hotfix)/ to allow any push to the feature or hotfix branch to trigger an event.
Change the dimensions of images in Markdown
Before this release, there were no controls for changing the size of images rendered within Markdown text areas. This often led to unwieldy images with no control over how much space they took up in descriptions and comments. You can now set the width and height of how images are rendered directly in Markdown by appending the {width=x height=y} attributes to the image reference. Sizes can be specified with pixels or percentages.
Variables in merge request description templates
When creating a merge request, your organization may define merge request templates. These templates help make sure certain information is filled in, provide checklists for tasks, and more. However, they don’t contain any Git-level information that may be important for the merge request. This can make it challenging to provide commit message details, branch information, or even author information in a standardized and repeatable way.
Merge request description templates now support variables. Use these variables to build both business logic and important Git information, like commit and authoring info, into merge requests. Template variables ensure incoming merge requests always include the information your project requires, without tedious manual effort from contributors.
Thanks to David Barr for contributing this!
GitLab Runner 15.7
We’re also releasing GitLab Runner 15.7 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:
- Dynamically mask resolved vault variables
- Mark secret values fetched from HashiCorp Vault integration as
raw - Configurable interval for disabling an unhealthy runner
Bug Fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
Improved access control for the GitLab Package Registry
When you configure your project, you can choose the visibility level and enable/disable project features and their permissions. For example, you could restrict access to Project members only for the repository, issues, merge requests, and more. Although you can control several features like this, you can only turn the GitLab Package Registry on and off. You can’t set the Package Registry visibility to project members only or everyone with access. This issue has made it difficult for you to create a central registry with approved, vetted packages for distribution throughout your organization. As a workaround, you’ve had to add everyone to the project, which introduces security risks.
To help make you more efficient, we’ve added feature-specific controls for the Package Registry. Now project Administrators and Owners have more flexibility and control over how they share the Package Registry. By default, the Package Registry visibility is set to project members only. For more information about what permissions are required to view, download, or update packages, refer to the Package Registry visibility permissions documentation.
On-demand DAST API GraphQL scans
As of GitLab 15.7, on-demand DAST API site profiles support configuring GraphQL APIs as the scan target. After selecting API as the site type, you can now select the GraphQL scan method and specify a GraphQL endpoint path. This ability has been available to DAST API scans in a CI/CD pipeline since we introduced the dast-api.gitlab-ci.yml template. With the switch from our legacy DAST API analyzer to our new analyzer for on-demand scans, we were able to add this functionality to our on-demand DAST API profiles.
See multiple findings in Code Quality changes view
We’ve improved GitLab Code Quality to make it easier to see and understand findings on merge requests when you’re reviewing changes. The Changes view on merge requests now supports showing more than one finding on each line, and you can now expand the findings to view them without continuing to hover over them.
This change is now active on GitLab.com. We plan to enable the feature flag by default for Self-Managed instances in GitLab 15.8.
Add finished_after filter to Deployments API
With this update, you can filter the list of deployments in a project by finished_before or finished_after dates, to efficiently search for the relevant deployments in your workflow. Previously, filtering was allowed only by the updated dates.
Search for environments within folders
With this release, we improved support for searching for environments. Previously, you needed to type out the complete name of an environment if it was in a folder. Now, the search bar matches environments’ names, even if they are nested.
Use the current project by default in GitOps configurations
When you install the agent, you typically create an agent without a configuration file. However, many features of the agent, including pull-based deployments, require a valid configuration.
In previous releases, pull-based deployments required you to specify the project where the manifest files are stored. If you had multiple projects, you needed a custom configuration file for each project. Now, you can omit the project ID and the agent will use the manifests in the current project. If your projects use the same conventions to store their manifests, you can use the same configuration file to set up an agent in every project.
Set default compliance framework for new projects in a group
In previous versions of GitLab, you could create a compliance framework for a group but needed to apply it to each new project individually.
Now you can set a compliance framework as the default framework to apply to new projects created in a group. Existing projects don’t have the default framework automatically applied.
Geo replicates dependency proxy
Geo now replicates the dependency proxy pull-through cache, which means that a populated cache of images is available at the newly promoted site after a failover. You can now be confident in performing regular failovers and avoid hitting Docker Hub rate limits, thus compromising the operational capabilities of the promoted site. This will help deliver a seamless failover experience to the end users.
Improved design for filtering global search results
Previously, global search scopes appeared as tabs below the search bar. This design wasn’t very intuitive and limited the number of available filtering options.
With this release, global search scopes now appear on the left sidebar. The new design makes it easier to filter results and allows for additional filtering options depending on content types. With this improvement, every page in global search results has a left sidebar and a consistent layout.
Specify custom NTP server when running Geo health check
For Geo to function correctly, the clocks between Geo sites must be synchronized. When running Geo health checks, you can now specify a custom NTP server to override pool.ntp.org. This change lets you validate your clocks if you are using your own time server, or if you set up Geo in an offline environment and it can’t reach the default NTP server.
Automatic disabling of failing webhooks
To protect GitLab and users across the system from any potential abuse or misuse, we’ve implemented a feature to disable webhooks that fail consistently.
- Webhooks that return response codes in the
5xxrange are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours. - Webhooks that fail with
4xxerrors are permanently disabled.
All project owners and maintainers are alerted in the app to investigate and re-enable any failed webhooks.
This feature is now available on GitLab.com and self-managed instances along with feature enhancements including handling cold starts.
Disable personal access tokens with application setting
You can now disable personal access tokens (PATs) at the instance level with a new application setting. Previously, there was no option to disable PATs.
Mask sensitive portions of webhook URLs
As you create webhooks to integrate with external services and receive GitLab data for event-driven workflows, you might have to supply callback URLs that include sensitive data. With this feature, you can now mask personal tokens, passwords, usernames, domains, and any other sensitive data when configuring your webhooks.
Users cannot set a known weak password
When a user sets their password, the password is now checked against a list of known weak passwords. If the password matches an entry on the list, the user must choose a different one. This helps users choose more secure GitLab passwords.
Add spent time in the issue and merge request sidebar
Before 15.7, quick actions were the only way to add time spent on an issue or merge request. While this method works, it’s not intuitive for all users. To make recording time more efficient, you can now add time entries directly from the sidebar of an issue or a merge request.
Thanks for the contribution Marco Zille!
HTML comment support in the Content Editor
When you collaborate on a wiki page or blog post, you often come across inline HTML comments that are not meant to be rendered. Previously, the Content Editor would ignore these comments to reflect what the actual content would look like. The problem, however, was that making edits in the Content Editor could unexpectedly remove these comments from the file.
With this release, you can insert new HTML comments inline and edit comments already on the page. These comments appear in a way that indicates they won’t be rendered. This feature can help you manage longer wiki pages and is an important step towards editing issue descriptions and comments in future releases.
Add custom names to pipelines with workflow:name:
For some projects, the same pipeline can be configured to run differently for different variables or conditions, creating very distinct outcomes for successful pipelines. It can be hard for you to determine which version of that pipeline ran since there is no indication about the inputs used for that particular run. While labels like scheduled and API help, it is sometimes still difficult to identify specific pipelines.
Now you can set a pipeline name using the keyword workflow:name to better identify the pipeline with string, a CI/CD variable, or a combination of both.
Job execution status badge
The new job execution status badge in Admin Area > Runners and the {group_name} > CI/CD > Runners displays an at-a-glance indicator to determine if there are active jobs on a specific runner in the fleet. This iteration aims to simplify troubleshooting runner queue issues that impact time-to-result for CI builds.
Dependency scanning support for npm lockfileVersion 3
GitLab Dependency Scanning now supports parsing and scanning dependencies stored in npm lockfiles where lockfileVersion: 3 is set.
See multiple Code Quality scan reports per pipeline
GitLab Code Quality includes an MR widget, a pipeline report, and MR diff annotations to help you find and fix problems in your code. Many tools, including code scanners and linters for technical documentation, can output results in Code Quality’s open report format.
Previously, you could only see results from a single scan in the pipeline report and MR diff annotations. This made it harder to add custom scanning tools to your pipelines.
Now, all of the Code Quality views show results from all report artifacts saved in a pipeline.
This new feature was enabled in GitLab.com in GitLab 15.6. The feature flag is now also enabled by default for Self-Managed instances in GitLab 15.7 and newer.
Static Analysis analyzer updates
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.7 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- Brakeman-based analyzer updated to version 5.3.1. See CHANGELOG for further details.
- CodeClimate-based analyzer updated to version 0.87.3. We’ve also disabled a network call that checked for available updates. See CHANGELOG for further details.
- Gitleaks-based analyzer updated to add a detection rule for systemd machine IDs and to exclude
go.modandgo.sumfiles from scanning. See CHANGELOG for further details. - KICS-based analyzer updated to version 1.6.5. See CHANGELOG for further details. This version adds new rules, improves performance, and fixes a bug where some Terraform configurations could cause the analyzer to crash.
- Kubesec-based analyzer updated to fix a bug for manifests with multiple objects. See CHANGELOG for further details.
- NodeJSScan-based analyzer updated to version 0.3.4. See CHANGELOG for further details.
- Semgrep-based analyzer updated to improve performance of built-in Python rules and support automatic vulnerability resolution. See CHANGELOG for further details.
- Multiple analyzers updated to include
gitso that the analyzer can remove vulnerabilities in files that aren’t committed to the repository.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
For previous changes, see last month’s updates.
GraphQL API for environment and deployment permissions
We have exposed user permissions for environments and deployments through GraphQL. Now you can fetch user permissions for actions, such as update or destroy, for an environment or deployment via API.
Restrict access to a tunnel to specific environments
You can use the CI/CD tunnel provided by the GitLab agent for Kubernetes to integrate your existing CI/CD workflows with your Kubernetes clusters. To save on resources and simplify maintenance, you can share a tunnel with multiple groups and projects.
In previous releases, if a CI/CD tunnel was available for a project, you could use it from all branches and in all environments. However, you could not restrict access to tunnels. Now, you can restrict access to tunnels to certain environments, or to environments that match a wildcard pattern.
Scan execution policy support for defining runner tags
Tags can now be defined in GitLab Scan Execution policies. This gives you the flexibility to specify which Runners will be used to execute your scan execution policy jobs.
Autocomplete suggestions for users in the global search bar
In the search bar, you can now see autocomplete suggestions for users. When you select a user, their profile page appears.
GitLab chart improvements
- Cloud Native GitLab replaces
alpine-certificatesbehaviors withgitlab-basein an upcoming release. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern ongitlab-base. This means operational service containers will share a common root layer, which provides an efficiency boost to Pod instantiation time. The user impact of this, is that we will be changing the image name and tags used. We will maintain a mirrored tag for a short period.
Omnibus improvements
- GitLab 15.7 includes Mattermost 7.5, with message threads in calls, new Board templates, Board filtering by text properties, Board metrics, Channel user last activity, and more. This version also includes security updates and upgrade from earlier versions is recommended.
- GitLab 15.6 includes packages for openSUSE Leap 15.4.
Bug fixes
Some of the notable bug fixes in 15.7 are:
- Groups can have no owner after deleting members
- Fix the PagerDuty webhook integration
- Fix inclusion validation for CI entries
- Fix error-generating group access tokens when LDAP group sync is enabled
- Fix permissions for bot accounts so they don’t create projects in their personal namespace
- Avoid collisions of ids while streaming audit events
EnqueueFromTransactionErrorexception while enqueuingAuditEventStreamingWorker- Changing the time zone does not affect audit logs
- Fix fields for the
securityReportFindingsGraphQL scanner - Query
groupVulnerabilitiestimeout when the All statuses filter is applied against a large set of vulnerabilities - Vulnerability state changes to Dismissed when an MR that has a security finding with an issue is merged
- Query timeout issues on
Security::Scans::PurgeWorker - Changes in the audit events view remove all events when using an auditor account
- Fix visibility of the Service Desk name text box in general settings
- Fix a Service Desk incoming mail issue after upgrade to v15.3.1
- Exported relations in GitLab Migration fail to download if stored in S3 object storage
- GitLab Migration gets stuck in the importing state when migrating from CE to EE
- GitHub import doesn’t associate the user even when they sign in using the GitHub icon
- Mirrored project with LFS files returns
Object does not exist on the server or you don't have permission to access it - Cancelation of GitHub repo import forwards to the GitLab user profile
auth - GitHub importer:
undefined method 'start_with?' for nil:NilClass - GitLab Migration UI hangs when updating namespace information
- GitHub API (Octokit) search query can grow too long and fail with an
HTTP 414 URI Too Longerror - GitHub PR comment threads not imported correctly
Elastic::ProjectTransferWorkershould handle missing namespaces- Convert
memory_limitto bytes forRssMemoryLimit - Incorrect storage statistics for
packages - Images are not deleted from the Container Registry UI
- Log error when failing to async delete container repositories
- Wildcard branch name not working
- Unable to unlink a security policy project when clicking the trash icon twice
- Scheduled scan execution policy does not work
- Scan result policy does not work when a user does not have permission to update project approval rules
AuditEvents::AuditEventStreamingWorker.perform_asynccannot be enqueued inside a transaction- Using
group_approverswith the project path results in invalid approval rules - Switching policy projects results in old policies for new and existing MRs
- Disassociating a policy project means GitLab will silently ignore it when reapplied for existing MRs
- Improve scan execution policy permission checks when creating pipelines
- MR changes fail to load when the source or target branch is deleted and the MR has conflicts
- Database: Fix
InvalidColumnReferencefor merge requests - Database: Fix
ForeignKeyViolationfor merge requests - Fix an edge case where an MR branch is not deleted
- Merge request widget actions ordered by importance, both visually and in the markup
- The Changes tab of an MR with no changes shows
NaNinstead of0 - The Changes tab breaks thread navigation in the Overview tab
- Thread navigation in the Changes tab causes unnecessary scrolling
- Going back to the Changes tab doesn’t work with thread navigation
- Frequent automatic logouts for SAML users
- The
gitlab_userresource always hasskip_confirmation=false - Broken watch API:
error: stream error: stream ID 5; INTERNAL_ERROR; received from peer - Multiple caches leading to a hash collision
- Downstream pipelines link in the mini-pipeline graph opens the MR page
- Dropdown in the mini-pipeline graph is difficult to interact with
/epicquick actions are not resolved from Service Desk issue templates- Allow customers to receive notifications from Service Desk issues after the issues are moved
- Require variable keys when scheduling a new pipeline
- GitLab.com pipeline jobs sometimes get stuck in the
createdstatus deploy-jobignores the previous stage if canceled and retried- No protected environment approval option available on the environment index page
- Issue labels don’t show in epics with both child epics and issues
- Spec failure:
spec/features/boards/boards_spec.rb:200 - Geo: Workaround for when a backup cannot be restored with
pg_stat_statementsenabled - SAST:
gl-sast-report.jsonhas incorrect ownership and/or permissions - SAST: Various analyzers return
Could not detect git executablewarnings - SAST:
kubesecanalyzer will not report all vulnerabilities for manifest with multiple objects - SAST: Upstream
kicsanalyzer v1.6.2 causes anexit statuserror - Code Quality reports failing to populate the MR widget
- Work item is refetched with
id=nullwhen the task modal is closed - Add missing hover text for the edit icon in task description
- Cannot assign a person to a task from the dropdown list or remove an assigned person
- Fix a bug in
uploads_rewriter - Fix errors that prevent project deletion
gemnasium-pythonfails:vrange/pythonincompatible withpackagingv22.0
Performance improvements
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 15.7, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 15.7 are:
- Improve the
group#vulnerabilityGradesGraphQL query - Remove large backlog of stale export jobs
- Improve the PyPI metadata endpoint performance
- Cache deduplicated
selfsize of container repositories in Redis - Develop a more performant API for merge request changes
- Optimize Redis polling in tunnel finder
- Geo: Many Postgres locks on the Tracking Database from
VerificationTimeoutWorker
Usability improvements
In every release, we make great strides in improving the overall effectiveness and usefulness of our product.
We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.
In GitLab 15.7, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 15.7:
- Admin view instance-level environment variable has an extra Environment scope text box
- Add an audit event for group SAML
extern_uidupdates - Create a toggle to monitor visibility settings
- The npm registry now supports npm audit
- Don’t display details for packages not in the default status
- Remove the
repository importingerror from the container registry - Add an Assign yourself button to the Reviewers section in the merge request sidebar
- Add a Search Within token to issues list search
- Selecting an Insights custom analytics report does not retain your selection
- Add a
CI_ENVIRONMENT_NAMEvariable to rules - Explicitly respond with an error when an agent cannot be found
- Configure connection headers using a command-line argument
- Allow sorting by health status in the issue list
- Improve the error messaging when fetching remote includes is timing out
- Add a GET endpoint for merge trains on a branch
- Improve push performance through upstream Git
receive-packoptimizations
Deprecations
New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.
- DAST API scans using DAST template is deprecated
- DAST API variables
- DAST ZAP advanced configuration variables deprecation
- DAST report variables deprecation
- KAS Metrics Port in GitLab Helm Chart
- POST ci/lint API endpoint deprecated
- Shimo integration
- Single merge request changes API endpoint
- Support for REST API endpoints that reset runner registration tokens
- Support for periods (.) in Terraform state names might break existing states
- The Phabricator task importer is deprecated
- The gitlab-runner exec command is deprecated
- ZenTao integration
Removals and breaking changes
The complete list of all removed features can be viewed in the GitLab documentation.
from GitLab https://ift.tt/Yb8BsO2 #GitLab #DevSecOps
Comments
Post a Comment