GitLab 15.2 released with live wiki diagram previews and redesigned merge request reports
Today, we are excited to announce the release of GitLab 15.2 with Live preview diagrams in the wiki WYSIWYG editor, Incident timelines, Group and subgroup scan execution policies, Change failure rate chart for visualizing software stability, and much more!
These are just a few highlights from the 40+ improvements in this release. Read on to check out all of the great updates below.
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.3 release kickoff video.
This month's Most Valuable Person (MVP) is kyrie.31415926535
This month we are thrilled to recognize someone nominated in 15.1 for their contributions to improving the security of all GitLab users! kyrie.31415926535 contributed changes that prevent users from adding weak SSH keys. The best place to stop a security problem is before it starts. This change serves as an additional safeguard to protect GitLab accounts from compromise.
Thank you so much kyrie.31415926535 for your contribution!
Live preview diagrams in the wiki WYSIWYG editor
GitLab Flavored Markdown includes extensions to support Mermaid, PlantUML, and Kroki diagrams but writing anything other than the most basic diagrams can be cumbersome without a live preview. You can toggle between the raw source and static preview and there are external tools you can use to write these diagrams, but the shift away from your content can be distracting.
GitLab 15.2 introduces a live rendered preview of your diagram in the wiki’s WYSIWYG editor. Now, as you write your diagram in a specialized code block we will detect the diagram type and display a preview icon. When enabled, the live preview renders above the code block and updates as you type, so you can ensure your formatting is correct and the output will be exactly what you expect.
Merge request reports redesign
Merge request reports are an important part of code review, providing insights into the impact of changes and improvements to meet project standards.
Report widgets now all follow design guidelines for layout, hierarchy, and content sections, making them consistent, scannable, and utilitarian. These improvements make it easier for you to find actionable information in each report.
Enforce IP address restrictions for Git over SSH
Limiting access to requests from a trusted set of IP addresses may improve security. Until now, only the API and UI supported such access restrictions; SSH access was blocked entirely. SSH now also adheres to this restriction, and grants access only to requests coming from IP addresses in your list.
Change failure rate chart for visualizing software stability
In this release, we added a new trend chart for the DORA Change failure rate metric. This chart shows the percentage of deployments that cause an incident in a production environment. GitLab measures the change failure rate as the number of incidents divided by the number of deployments to a production environment during a given time period.
This is the fourth DORA chart available in GitLab that provides insights into value stream velocity and reliability trends.
Group and subgroup scan execution policies
Your security and compliance teams can now apply policies uniformly to all projects by scanning execution policies at the group and subgroup levels. This functionality is especially helpful for large organizations who have a large number of projects. Policies defined for the group or subgroup will flow down and apply to all child projects. To get started, ask your group owner to link a security policy project to your group on the Security & Compliance > Policies page.
Currently scan execution policies are the only policy type that is supported at the group and subgroup levels. You can track the efforts to add group and subgroup level support for scan result policies in this epic.
Incident timeline
Capturing what happened during an incident is an important practice that facilitates learning and the opportunity for improvement. Yet, asking incident responders to take on additional administrative tasks when they’re busy fire-fighting, or trying to reconstruct the timeline of events post incident lead to incomplete or less than accurate information.
GitLab incident timeline is designed to make information capture during an incident, or post incident, easy and efficient. In the Incident timeline MVC, we make it possible to add new timeline events manually, delete a timeline event, and view the incident timeline in a dedicated tab within an incident issue.
Set the image pull policy in pipeline configuration
You can select different pull policies for how a GitLab Runner downloads Docker images in CI/CD jobs. always (the default behavior) ensures the image is always downloaded, if-not-present downloads an image only when a local version does not exist, and never only uses the local version (never download an image).
Previously, you could define the pull policy only at the runner level. In this release we’ve added the ability to define the pull policy at the pipeline level. Use pull_policy in your .gitlab-ci.yml to define different pull policies at the job or pipeline level. This feature is not supported by shared runners.
Audit events for group-level merge request settings
GitLab now records additional audit events when changes are made to group-level merge request settings. These are in addition to project audit events that record changes to the same settings on projects. Specifically, audit events are now created when changes are made to groups to:
- Prevent approval by author
- Prevent approvals by users who add commits
- Prevent editing approval rules in projects and merge requests.
- Require user password to approve
- Remove all approvals when commits are added to the source branch
These audit events can help you know that the settings and default configurations for your group-level merge request settings have been put in place correctly and that they have not been changed. This is especially important because these group-level settings will cascade down to child projects. Governance and visibility over these changes will help you strengthen separation of duties and further simplify audits.
Custom HTTP headers for streaming audit events
You can now add custom HTTP headers to be sent with streaming audit events! This improvement makes it easier to integrate with 3rd-party systems that require specific headers on messages they receive. Custom headers can be used to do things like adding authentication information, adding routing information, or tagging which project an event came from.
Previously, you had to use a proxy server to add these custom headers to streaming audit events. Setting up this proxy was time-consuming, error prone, and added additional complexity to your organization. Setting custom headers directly within GitLab makes integrating with other tools and driving automation much simpler and allows you to do what you need directly within the GitLab platform.
To add custom HTTP headers, use our GraphQL APIs to add a new header as a key/value pair. You can also update and remove headers.
Improvements to users’ contribution calendar for private contributions
We fixed an issue where private contributions did not display in users’ contribution calendar graph. Now when you select Include private contributions on my profile in your profile settings, private contributions remain visible even when you’re removed from a project.
Streaming audit events for merge request creation
You can now monitor with audit events when merge requests are created inside your groups. The audit event includes information like:
- User name of the merge request author.
- Creation timestamp.
- Details of the newly-created merge request.
This gives you visibility of the activity inside your projects and source code so that you can take action if needed.
These events generate a high volume of data, so they are only available as streaming audit events.
Thank you Linjie Zhang for this contribution!
Verification token displayed in UI
The GitLab UI now displays the verification token value for each streaming destination! This makes it easy to quickly see what the value is, check it against logs you see, or copy it to other tools that will receive the streaming audit event data.
Previously, if you needed to get this value, you had to use an API to list all audit destinations in a group and find the value. This was complicated and an extra step, so we are excited to make this much easier by putting the value directly in the UI!
Persist last used Wiki editor
The WYSIWYG editor was introduced in the wiki way back in GitLab 14.0 allowing you to write Markdown using visual formatting tools and a giving you a real-time preview of your content as you write. However, since its release, you had to manually switch to use the WYSIWYG editor every time to started editing a wiki page.
GitLab 15.2 will now persist your last used editor in the wiki. You’ll save time when editing consecutive pages by jumping right into your preferred experience without having to switch between editors every time.
GitLab Runner 15.2
We’re also releasing GitLab Runner 15.2 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.
Bug Fixes:
- DEBUG set as a variable in a job definition causes random failures
- Update containerd version to 1.4.12
The list of all changes is in the GitLab Runner CHANGELOG.
Programmatically delete duplicate package assets
You use the GitLab Package Registry to publish and share your project’s packages. When a package is published, it includes package assets. For example, each time you publish a Maven package, it includes a pom and jar package. Some formats, such as Maven, NuGet, and generic packages, allow you to publish duplicate packages, resulting in hundreds or thousands of duplicate package assets. In previous versions of GitLab, you would only be able to delete these assets one at a time using the user interface or the API. Now you can use a cleanup policy to define a maximum number of duplicate assets to keep. For example, if you define a cleanup policy to preserve five duplicate versions of an asset, only the five most recent assets are kept the next time the policy runs.
The introduction of cleanup policies for Packages helps reduce the amount of storage used for your project and makes it easier to navigate the user interface by reducing clutter.
License compliance support for Gradle implementation directive
Gradle 6 introduced a new implementation directive for defining dependencies. Beginning with Gradle 7, this new directive became mandatory and replaced the previous compile directive. GitLab 15.2 introduces support for detecting dependencies that are introduced using this new directive.
Edit protected environment approvals in project settings
Previously, to edit the number of approvals required for deployment to a protected environment, you had to use the API, which could be cumbersome. Starting in 15.2, you can edit the number of required approvals directly in the project’s settings.
Group-level UI for protected environment settings
Previously, if you wanted to configure group-level settings for protected environments, you had to use the API. With this release, you can now view and edit these settings in the UI. This change allows you to more easily set policies for which users and groups can deploy to environments across projects within a group.
Updated cluster version support, including Kubernetes 1.23 and 1.24
If you use Kubernetes, GitLab wants to ensure you have full functionality when you upgrade your clusters to the most recent Kubernetes version. While many of you use GitLab to deploy your Kubernetes clusters, until recently there was no official support for Kubernetes 1.23 and 1.24. This release brings full support for all of the Kubernetes-related features from those versions.
Together with providing support to Kubernetes version 1.23 and 1.24, we are changing our Kubernetes support policy to be more predictable than it was in the past. With the new support policy, we plan to add support to every new Kubernetes minor version three months after the initial release, and we will support the last three Kubernetes minor versions.
Omnibus improvements
- GitLab 15.2 includes Mattermost 7.0, with the general availability of Collapsed Reply Threads, voice calls and screen share (beta), messaging format toolbar, Playbooks inline editor, usage statistics, and the ability to change triggers and actions mid-run. This version also includes security updates and upgrade from earlier versions is recommended.
Audit events when two-factor authentication is disabled
GitLab now records an audit event when a user disables their two-factor authentication (2FA) settings.
This audit event helps you ensure that all the users in your instance are properly using 2FA (and identify when the security of a user’s account has been lowered), so that you can investigate and take action.
Disable user 2FA using API
Administrators can disable 2FA for specific users using the API. This is useful when a user has lost or forgotten their backup codes for their primary token generator.
After the administrator disables 2FA for that user, the user can set up 2FA from scratch.
Streaming audit events for Git operations
You can now monitor the Git activity inside your groups with new audit events that are recorded when users push to or pull from repositories. This will include information such as the user name, the timestamp, and the project that was pulled from or pushed to.
These events generate a high volume of data, so they are only available as streaming audit events.
Streaming audit events for project forks
You can now monitor the project forking inside your groups with new audit events that are recorded whenever a project is forked. This includes information such as:
- The user name of the user that forked the project.
- The timestamp of when the project was forked.
- Details of the forked project.
This gives you visibility on where your projects and source code are being copied to, and by whom, so that you can take action if needed.
These events potentially generate a high volume of data, so they are only available as streaming audit events.
Thank you Linjie Zhang for this contribution!
Improved and faster file browsing and syntax highlighting
In recent months, we made multiple changes to improve the experience of browsing a repository and viewing source files. Rather than reloading the full page when moving from folder to folder, we now display repository files and folders with a single VUE application. Our repository tree view is more performant and stable now, and working with files is faster. We’ve also switched from server-side transformations for files to client-side syntax highlighting. The rendering time for large files is now up to 66% faster.
Filter jobs by status on the jobs page
When you’re troubleshooting a pipeline that is behaving unexpectedly, you may want to filter for the jobs with a particular status. Previously, that would require looking at the full list of jobs or use the GitLab API to manipulate the data outside of GitLab.
Now you can filter jobs by their status directly on the job page, so you can see all jobs with the same status in your project.
Predefined CI/CD variable for project description
GitLab CI/CD provides many useful predefined CI/CD variables out-of-the-box, but did not have one for your project’s description. In this release we now have the CI_PROJECT_DESCRIPTION predefined variable, which makes it easy for you to access the project description from within a CI/CD job. Thank you to @nejc for this contribution!
Faster Secret Detection
We’ve optimized GitLab Secret Detection to use a new technique that cuts scan times by skipping expensive operations when they can’t possibly match. The analyzer now first scans for exact strings before running full matching rules.
This optimization significantly reduces scan duration in our testing, cutting scan times by 50–75% in medium-sized repositories. It works for secrets that have a defined prefix or known identifier; for example, GitLab Personal Access Tokens start with glpat- by default.
We’ve updated the built-in secret detection rules to use this faster method. If you’ve added custom rules, you can optimize them by setting a keywords value for them in your custom GitLeaks TOML configuration file. At least one string in keywords must match before the regular expression pattern runs.
We hope to make this optimization easier to apply in the future after delivering this first iteration.
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.2 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- CodeClimate analyzer updated to version 0.85.29. See CHANGELOG for details.
- Add support for
eslint-8channel. - Don’t analyze files or allow LinkLocal addresses in
preparestep.
- Add support for
- Kics analyzer updated to handle exit codes better. See CHANGELOG for details.
- Kubesec analyzer updated to include Kubesec 2.11.5 and Helm 3.9.0, and to handle an issue with helm output. See CHANGELOG for details.
- PMD-Apex analyzer updated to version 6.45.0. See CHANGELOG for details.
- Semgrep analyzer engine updated to version 0.98.0. See CHANGELOG for details.
- Improve performance, fix bugs, and otherwise improve scanning engine.
- Bypass language-based matcher (which decides whether to run the scanning process) if you define custom rules. This makes it easier for you to define custom rules for languages that aren’t covered in GitLab-managed rulesets.
- Secrets analyzer updated to remove built-in rules for Social Security Numbers (SSNs) and apply new optimizations. See CHANGELOG for details.
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.
Fetch secrets based on deployment tier
Secrets can be assigned based on the deployment tier of an environment. In this release, we include the deployment_tier in the JSON Web Token (CI_JOB_JWT) so that users can fetch secrets per a specific deployment tier.
API to retrieve agent server (KAS) metadata
After we released the agent for Kubernetes, one of the first requests we got was for an automated way to set it up. In the past months, Timo implemented a REST API and extended the GitLab Terraform Provider to support managing agents in an automated way. The current release further improves management of the agent specifically, and of GitLab in general, by introducing a /metadata REST endpoint that is the superset of the /version endpoint.
The /metadata endpoint contains information about the current GitLab version, whether the agent server (KAS) is enabled, and where it can be accessed. This change improves upon the previous functionality, where you had to put the KAS address in your automation scripts manually.
Enforce per-plan webhook rate limits
Webhook rate limits will now be enforced for GitLab.com users to protect the performance and availability of the GitLab application. In return, the limit protects performance for all tenants. Limits are applied per plan and per namespace and are based on the number of seats in your subscription, starting at 500 and up to 13,000 calls per minute per top-level namespace.
Geo supports BuildKit cache images
With GitLab 15.2, Geo supports replication of BuildKit cache images. With the support of the BuildKit cache image format in GitLab 15.2, and the addition of support for OCI container images in GitLab 15.1, Geo now supports a broader list of container types.
GitLab chart improvements
- When using the horizontal pod autoscaler to automatically scale the number of pods in a Kubernetes deployment of GitLab (in this case, Gitlab.com), we noticed that scaling behavior can be erratic due to the spiky nature of the CPU profile being observed. To see less rapid scaling events we have added support for
v2beta2andv2which add significantly more control over scaling events.
Bug fixes
Some of the notable bug fixes in 15.2 are:
- GitLab Importer fails to import a group when subgroup with the same name exists
- Display only the latest OAuth token per application
- Group Access Token cannot access project with Git over HTTP when added as a member through project sharing
- Increase Webauthn credential XID length
- Findings dismissed in pipeline don’t update vulnerability report
- Vulnerability Slack notifications are not sent
- Container Scanning is not available in Free tier
- Agent vulnerability resolution doesn’t account for multiple workloads / agents
- Cluster image scanning does not work with non-default namespace or service account
- Group and project-level security policy can be bypassed
- Show custom integration error message when testing settings
- Creating epic in scope board should add label
- Some epics displaying twice in roadmap as child epics and top-level epics
- Only Reporters receive email notifications for internal comments
- Environment approval not visible when multiple approval rules are configured
- Restarting auto-stopped environments does not work (intermittent)
- Python Notebook diffs were being displayed twice
- Intermittent crash when generating diffs for some Python Notebooks
- Diffs not loading for collapsed files containing Python Notebooks
- Statement timeout deleting cluster agents
- Error when ingressClassName is supported by API but not by the ingress controller
- Gitlab doesn’t detect the deployment pods after K8s cluster upgrade to v1.22
- Support parsing manifests with yet unknown Custom Resources
- Deployment with kpt using old version
- Cannot parse reference discovery in an empty repository
- Handle newline character on agentk token
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.2, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 15.2 are:
- Return the creation timestamp for containers to improve the cleanup policy
- Improve performance of loading OAuth apps and tokens
- Speed up the loading of stage job lists
- Generating Python Notebook diffs now takes 12x less time and 8x less memory
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.2, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 15.2:
- Show project name in Container Registry breadcrumb
- Improved layout of Package group settings
- Filter files by extension in merge requests
- Remove extra lines from Python Notebook diffs
- Improve styling for Python Notebook diffs
Deprecations
New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.
Removals
The complete list of all removed features can be viewed in the GitLab documentation.
Gitaly security update
self_signed_cert key in gitlab_shell['http_settings'] is removed
In an update to the GitLab Shell, the option to validate self-signed certificates was deprecated and removed in GitLab 14.8 because it allowed for man-in-the-middle attacks. Gitaly has been updated to reflect this deprecation and removed gitlab_shell['http_settings'] as well.
from GitLab https://ift.tt/n9ZYAcz #GitLab #DevSecOps
Comments
Post a Comment