GitLab 16.2 released with all new rich text editor experience
GitLab 16.2 released with all new rich text editor experience, command palette, machine learning model experiments tracking, new customization layer for the Value Streams Dashboard and much more!
These are just a few highlights from the 110+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 208 contributions they provided to GitLab 16.2! 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 16.3 release kickoff video.
Xing Xin was recognized for a recent merge request to use quarantined repo for conflict detection. Karthik Nayak, a Sr. Backend Engineer at GitLab, noted: “Using quarantined repositories allows for avoiding stale objects in git repositories if an operation fails midway. Xing was able to recognize an RPC where we could introduce a quarantine repository and also responded to feedback with good pointers and was able to convince us around some questions with good knowledge about the codebase.”
Xing has been contributing to GitLab and the Gitaly project since 2020. A bytedancer from ByteDance, Xing also spends time in Alibaba Cloud and AntGroup, focusing on code hosting and engineer efficiency. Xing added that the “GitLab community inspired me a lot for both the best practices of managing code and the comments from all the kind reviewers. Hope to grow together with the community.”
Missy has also been an active member of the GitLab Contributor Community and regularly engages in community events, office hours, and on the Discord server. Both Lee Tickett and Marco Zille, members of the GitLab Community Core Team, highlighted Missy’s engagement with the wider community. Lee added that Missy has been “living our values”.
Missy shared that she has found great enjoyment in her growing involvement in the world of open source at GitLab. She values the strong sense of community, the continuous learning opportunities, and shared passion for open source principles. As a backend developer with experience working with Ruby on Rails and Python, Missy has been an impactful GitLab contributor since 2022.
A big thanks to all of our community contributors this past release 🙌
GitLab 16.2 features an all-new rich text editing experience! This new capability is available for everyone, as an alternative to the existing Markdown editing experience.
For many, using the plain text editor for comments or descriptions is a barrier to collaboration. Remembering the syntax for image references or working with long tables can be tedious even for those who are relatively experienced with the syntax. The rich text editor aims to break down these barriers by providing a “what you see is what you get” editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.
The rich text editor is now available in all issues, epics and merge requests. We plan to make it available in more places across GitLab soon. You can follow our progress here.
We are proud of the new editing experience and can’t wait to see what you think. Please try the new rich text editor and let us know about your experience in this issue.
By default, Flux synchronizes Kubernetes manifests at regular intervals. Triggering a reconciliation immediately when a manifest changes by default requires additional configuration. With the GitLab agent for Kubernetes, you can push a change to your manifest and trigger a Flux sync automatically.
Properly storing, rotating, and managing signing keys can be difficult and typically requires the overhead of managing a separate Key Management System (KMS). GitLab now supports keyless signing through a native integration with the Sigstore Cosign tool which allows for easy, convenient, and secure signing within the GitLab CI/CD pipeline. Signing is done using a very short-lived signing key. The key is generated through a token obtained from the GitLab server using the OIDC identity of the user who ran the pipeline. This token includes unique claims that certify the token was generated by a CI/CD pipeline.
To begin using keyless signing for your build artifacts, container images, and packages, users only need to add a few lines to their CI/CD file as shown in our documentation.
If you’re a power user, using the keyboard to navigate and take action can be frustrating. Now, a new command palette helps you use the keyboard to get more done.
To enable the command palette, open the left sidebar and click Search GitLab (🔍) or use the / key.
Type one of the special characters:
> - Create a new object or find a menu item
@ - Search for a user
: - Search for a project
/ - Search for project files in the default repository branch
Code Suggestions now use Google Cloud’s customizable foundation models and open generative AI infrastructure, with generative AI support in Vertex AI.
GitLab Code Suggestions are routed through Google Vertex AI Codey API’s Data Governance and Responsible AI. As of July 22, Code Suggestions inferences against the currently opened file and has a context window of 2,048 tokens and 8,192 character limits. This limit includes content before and after the cursor, the file name, and the extension type. Learn more about Google Vertex AI code-gecko.
The Google Vertex AI Codey APIs directly support: C++, C#, Go, Google SQL, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift, TypeScript. And for infrastructure files, support: Google Cloud CLI, Kubernetes Resource Model (KRM), and Terraform.
When data scientists create machine learning (ML) models, they often experiment with different parameters, configurations, and feature engineering, so they can improve the performance of the model. The data scientists need to keep track of all of this metadata and the associated artifacts, so they can later replicate the experiment. This work is not trivial, and existing solutions require complex setup.
With machine learning model experiments, data scientists can log parameters, metrics, and artifacts directly into GitLab, giving easy access to their most performant models. This feature is an experiment.
We added a new configuration file to the Value Streams Dashboard for easier customization of the dashboard’s data and appearance. In this file you can define various settings and parameters, such as title, description, and number of panels and filters. The file is schema-driven and managed with version control systems like Git. This enables tracking and maintaining a history of configuration changes, reverting to previous versions if necessary, and collaborating effectively with team members.
The new configuration also includes the option to filter the metrics by labels. You can adjust the metrics comparison panel based on your areas of interest, filter out irrelevant information, and focus on the data that is most relevant to your analysis or decision-making process.
When invitations are sent to an incorrect email address, they can never be confirmed. Previously, administrators had to manually delete these accounts. Now, administrators can turn on automatic deletion of unconfirmed users after a specified number of days. Similarly, on GitLab.com, unconfirmed accounts will be deleted automatically after the specified number of days.
Feed tokens have been made more secure by only working for the URL they were generated for. This narrows the scope of feeds that can be read if the token was leaked.
By default, the GitHub importer uses a single access token when importing projects from GitHub to GitLab. An access token for a user account is typically rate limited to
5000 requests per hour. This can significantly reduce the speed of the importer when:
Importing multiple small to medium sized projects.
Importing a single massive project with a lot of data.
With this release, you can pass a list of access tokens to the GitHub importer API so that the API can rotate through them when rate limited.
When using multiple access tokens:
The tokens cannot be from the same account because they would all share one rate limit.
Tokens must have the same permissions and sufficient privileges to the repositories to import.
Previously, GitLab deployments were linked from the Jira development panel only when a Jira issue
was mentioned in either the branch or merge request associated with the deployment.
This was often inconvenient for users because it required them to deploy
from merge requests, which is not the typical workflow.
With this release, GitLab deployments also scan for Jira issue mentions in the messages of the
last 5,000 commits made to the branch after the last successful deployment. The GitLab deployment is associated with all of the mentioned Jira issues.
When you suggest changes in a merge request, you can now edit your suggestions more quickly. In a comment, switch to the rich text editor and use the UI to move up and down the lines of text. With this change, you can view your suggestions exactly as they will appear when the comment is posted.
The rich text editor is a new way of editing in GitLab. It’s available in merge requests, but also available alongside the plain text editor in issues and epics.
We plan to have the rich text editor available in more areas of GitLab soon and we are actively working on that. You can follow our progress here.
include is one of the most popular keywords to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.
In this release, we are expanding the power of the keyword so you can use when: never when using rules with include. Now, you can decide when external CI/CD configuration will be excluded when a specific rule is satisfied. This will help you write a standardized pipeline with better ability to dynamically modify itself based on the conditions you choose.
Previously users on the Free tier were only able to use our small Linux runner, sometimes causing longer CI/CD execution times.
We are excited to see our Free users accelerate their pipeline speeds.
The agentk component of the agent for Kubernetes requires a token to authenticate with GitLab. Previously, you could provide the token as-is, or as a reference to the Kubernetes secret that contains the token. However, you might operate in an environment where the secret is already available in a volume, and prefer to mount that volume instead of creating a separate secret. From GitLab 16.2, the GitLab agent Helm chart ships with this added feature thanks to a community contribution from Thomas Spear.
Geo adds the ability to resync and reverify individual items for all component types managed by the self-service framework. Now you can force a resync or reverification operation on any individual item managed by Geo by using the UI. This can help expedite a resync or reverification operation for failed items, or after changes have been applied to fix sync or verification errors.
With this release, we’ve extended Advanced Search to include group-level wikis. Users will now be able to find content in these wikis more easily and quickly than before.
In previous GitLab versions, security policies were not enforced on projects without a .gitlab-ci.yml file, or where AutoDevOps was disabled. In GitLab 16.2, security policies implicity enable CI/CD pipelines on projects that do not contain a .gitlab-ci.yml file. This is another step in ensuring compliance of security policies and allow you to enforce secret detection, static analysis, or any other jobs where builds are not required.
You can now export a report of compliance frameworks and their associated projects to a CSV file.
With the addition of the compliance frameworks report at the group level, you were able to see and
manage which projects your compliance frameworks applied to.
With the new export, you can keep a copy of that file for reference. You might keep the file as a
single source of truth for the ideal state of your project and compliance framework relationships. Or you
might send the file people in your organization who may not work in GitLab, but have an interest in seeing
which projects are tagged with which frameworks.
GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves.
We’ve released two improvements in GitLab 16.2:
Expanded language support: Advanced Vulnerability Tracking is now enabled for C#.
Better tracking: We’ve improved the tracking algorithm to handle whitespace and comments better in C, C#, Go, Java, JavaScript, and Python. We’ve also fixed issues with tracking certain Go functions.
We’re tracking further improvements, including expansion to more languages, better handling of more language constructs, and improved tracking for Python and Ruby, in epic 5144.
These changes are included in updated versions of GitLab SAST analyzers.
Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers.
You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports.
During the 16.2 release milestone, our changes focused on the Semgrep-based analyzer and the GitLab-maintained rules it uses for scanning. We released the following changes:
Updated rules to find additional vulnerabilities in Java and JavaScript.
Changed the default configuration for which files are ignored in scans by:
Removing .gitignore exclusion. Thanks to @SimonGurney for this community contribution.
Respecting locally-defined .semgrepignore files. Thanks to @hmrc.colinameigh for this community contribution.
Improved a rule related to Go memory aliasing. Thanks to @tyage for this community contribution.
Removed a -1 suffix added to the Semgrep rule IDs for JavaScript rules. This was added in GitLab 16.0 as a side-effect of an unrelated change, but interfered with customers’ existing semgrepignore comments.
In previous version of GitLab, you had to use the GraphQL API to add audit event type filters to your audit event streams.
Now, you can use the filter dropdown in the GitLab UI to see all the available audit event types, grouped by the
area of GitLab to which they are relevant, and search for the exact types you want to send in a stream.
This significantly reduces the time needed to add filtering to audit event streams because you no longer have to pull the entire list using the API and
search through the list manually.
You can now define custom CI variables, including their values, in the Scan Execution Policies editor. CI variables defined in a policy override the matching variables defined in the projects enforced by the policy. For example, a policy may define a CI Variable SAST_EXCLUDED_ANALYZERS to brakeman. When the scanner is enforced in a project, the scanner will run with the variable set to brakeman regardless of any variables defined in the project’s CI configuration. For each scan type, you can define values for default variables, also create custom key-value pairs for custom CI variables. This makes customizing a scan execution policy quicker and easier.
With this release, the GitLab for Slack app is available on self-managed instances. On self-managed GitLab, you can create
a copy of the GitLab for Slack app from a manifest file and
install that copy in your Slack workspace. Each copy is private and not publicly distributable.
You can now sync OIDC groups to the auditor role in GitLab. This allows automated user lifecycle management facilitated by OIDC to use the auditor role, which was previously unsupported in the role mapping.
You can now express your thoughts more creatively by adding emoji
reactions to comments in Design Management.
This feature adds a touch of fun and ease to collaboration, fostering better
communication and enabling teams to provide quick feedback in a more expressive
way.
For instances which store LFS objects in object storage without proxy download enabled, GitLab now processes LFS requests in bulk. This dramatically improves the performance of downloading a large number of LFS objects.
Previously, due to how LFS objects were fetched, GitLab created many very small requests which checked user permissions and redirected to the object stored externally. This had the potential to cause significant load and a reduction in performance. With this fix, we have reduced load on the primary GitLab instance and provided a faster download experience for our users.
We’re also releasing GitLab Runner 16.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.
Have you been thinking about moving your PyPI repository to GitLab, but haven’t been able to invest the time to migrate? In this release, GitLab is launching the first version of a PyPI package importer.
You can now use the Packages Importer tool to import packages from any PyPI-compliant registry, like Artifactory.
The built-in backup and restore tool adds the ability to skip specific repositories. The Rake task now accepts a list of comma-separated group or project paths to be skipped during the backup or restore by using the new SKIP_REPOSITORIES_PATHS environment variable. This will allow you to skip, for example, stale or archived projects which do not change over time, saving you a) time by speeding up the backup run, and b) space by not including this data in the backup file.
Thanks to Yuri Konotopov for this community contribution!
In previous versions of GitLab, when a default branch was fully protected, only project maintainers and owners could push an initial commit to a default branch.
This caused problems for developers who created a new project, but couldn’t push an initial commit to it because only the default branch existed.
With the Fully protected after initial push setting, developers can push the initial commit to the default branch of a repository, but cannot push
any commits to the default branch afterward. Similar to when a branch is fully protected, project maintainers can always push to the default branch but no one
can force push.
You can now select Google Cloud Logging as a destination for audit event streams.
Previously, you had to use the headers to try to build a request that Google Cloud Logging would accept. This method was prone to errors and
could be difficult to troubleshoot.
Now, you can select Google Cloud Logging as the destination for the stream and provide your project ID, client email, log ID, and private
key to allow for a more seamless integration.
When reviewing a list of dependencies, it is important to have an overall view.
Managing dependencies at the project level is problematic for large organizations that want to audit their dependencies across all their projects.
With this release, you can see all dependencies at the project or group level, including subgroups. This feature is off by default behind feature flag group_level_dependencies.
Scan execution and scan result policies will allow you to scope enforcement to branches that are “Default” branches or “Protected branches” across the many projects a policy is enforcing. Rather than requiring policies to specify branch names explicitly, policies can be enforced more broadly and ensure branches with atypical names are not excluded from compliance.
Branch rules can be configured across our various security policy rule types by using the branch_type field:
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 16.2.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback