GitLab 15.0 released with WYSIWYG for Wiki, container scanning in all tiers
GitLab 15.0 with container scanning now available on all tiers, internal notes for issues epics, linking external organizations and contacts to issues, GitLab SaaS runners on macOS and much more!
Lee has been instrumental in building the foundation for our CRM feature. He has contributed to 7 issues and many more merge requests to deliver this over the past few milestones. This foundation allows users to set up and link organizations and contacts to issues directly in GitLab making it easier to track customer requests and deliver on their work.
GitLab 15.0 includes a few exciting improvements to speed up your workflow in the WYSIWYG Markdown editor for your wikis.
First, you’ll find no more un-styled, monochrome code blocks: choose from over 100 languages in the dropdown list above the code block so your CSS, YAML, and Python code are distinct from each other with accurate syntax highlighting. The code blocks will even inherit your preferred syntax highlighting theme. You can also quickly copy the code block to your clipboard for use in your code editor of choice.
You’ll also find working with links and media in the WYSIWYG editor easier than ever. Previously, you had to select from the editing toolbar to change a selected link or image on your wiki page, with some edits requiring you to delete the link or image and re-create it. Editing links and images is now easier, with a new popover menu that appears when you select a link or attached image. From the menu you can quickly edit a link’s destination URL or description, copy the link or image to your clipboard, or even remove the link or image from the page.
OpenSearch is an open source Elasticsearch fork. Prior to GitLab 15.0, Advanced Search was not compatible with OpenSearch. If you used AWS-managed services, you had to use older versions of Elasticsearch.
You can now take full advantage of OpenSearch for Advanced Search.
In GitLab 14.10 and earlier, groups supported only one set of iterations. It made it difficult for different teams that worked in a single group to have autonomy with scheduling and tracking their issues from iteration to iteration. To improve this, we’re adding the ability for a group to manage multiple sets of concurrent iterations with iteration cadences. This allows each team to have control over the start day and duration of each iteration in their iteration cadence.
The day-to-day management of iterations is now much more efficient too. When you create a new iteration cadence, select the first day of your first iteration, how many weeks each iteration should be, and how many upcoming iterations GitLab should maintain for you. You can also optionally enable unfinished issues to automatically roll over from one completed iteration to the next. After a cadence is created, GitLab automatically creates the specified number of upcoming iterations.
You can now also scope an issue board or issue list to an iteration.
All existing iterations in a group will be converted to an iteration cadence with no changes to underlying iteration data. Additionally, to better support future enhancements to iterations, such as iteration velocity and volatility and capacity planning, we’ve deprecated the ability to manually create and delete individual iterations and will remove this functionality in 16.0. Learn how to migrate to automated iteration cadences.
In many cases, organizations want to keep issues and epics public, but apply stricter governance to conversations within them. For example, when using GitLab issues as part of Service Desk workflows, organizations may want to make core details about an issue public, but not to expose customer-specific confidential data broadly.
With internal notes, you can redact discussions with internal or customer data that should only be visible to certain users, while keeping the core details about an issue public. Internal notes in issues or epics can only be seen by the issue author, assignee, and group or project members with at least the Reporter role.
Thanks @leetickett for collaborating with our team on this feature!
Link contacts to issues with the /add_contacts quick action.
View issues associated with a given contact or all contacts belonging to an organization.
The customer relations feature is not enabled by default, and can only be managed from a top-level group. If you want to help shape the future direction for customer relations management within GitLab, please contribute to this issue.
Thanks @leeticket for the dozens of contributions and countless hours spent leading this effort!
Container Scanning helps developers to easily find known security vulnerabilities in dependencies that are installed in their container images. With GitLab 15.0, we are making the basic Container Scanning features available in every GitLab tier.
Using CI/CD variables with the environment keyword in your CI/CD configuration is great, because it lets you create environments dynamically. While this is already a powerful feature, there were still some limitations, because you could not use nested variables to define environments.
Starting in GitLab 15.0, you can nest variables inside other variables, and have them all expand the way you expect. This makes dynamic environments even more powerful due to the increased flexibility!
In previous versions of GitLab, changes to the group IP allowlist did not generate audit events. This made it difficult to know who changed what, and when, when multiple people were modifying the allowlist. Now, any changes to group IP allowlists generate audit events.
We continue to add support for more release metadata to GitLab migration. In GitLab 15.0, we’ve added project releases milestone. This metadata will help you migrate more of the release data without needing to manually copy over missing release attributes.
In previous versions of GitLab, personal access tokens could be deleted only by the ID. Because none of the endpoints return an ID from a given value, you couldn’t delete a personal access token if you only had the token value.
You can also now use the personal_access_tokens/self endpoint to
revoke a PAT with a single request. The endpoint revokes the PAT used to make the request, making it easy to quickly revoke PATs in case of a leak.
Issue descriptions are used to capture a lot of different types of information such as checklists, outlines, and implementation details. You can now easily reorganize a description’s list items by dragging and dropping them without having to edit and save the full description.
GitLab 15.0 brings finer-grained control over group-level wiki visibility that matches the options already available on project-level wikis.
Now you can choose whether your wiki is visible to everyone with access to the group, restrict its access to just group members, or even disable visibility completely. Group administrators can find these options in the Group Settings page.
Tracking monthly CI/CD usage for public projects was hard, especially across multiple projects in a namespace. You could not easily see what project or projects were using shared runners the most.
Now shared SaaS runner usage for each user namespace is displayed along with the CI/CD minutes on the Usage Quota page. You can see how much each project has used the shared runners and how minutes usage is trending over time.
Previously, it was difficult to use binary files in your CI/CD pipelines because CI/CD variables could only contain text values. This made it difficult to make use of profiles, certificates, keystores, and other secure information, which are important for teams building mobile apps.
Today we are releasing Project-level Secure Files in open beta. Now you can upload binary files to projects in GitLab, and include those files in CI/CD jobs to be used in the build and release processes as needed. Secure Files are stored outside of version control and are not part of the project repository.
Please leave us your feedback about your experience with this feature in the feedback issue.
Previously, if wanted an at-a-glance view of a runner’s relevant information, you had to switch between screens or even use the API to retrieve the details. Now, administrators can view the runner’s executor, architecture, and platform on the runner’s detail view. These details can help you quickly determine essential details, which are critical for troubleshooting issues or managing day-to-day operations and maintenance tasks.
Prior to this release, you had the ability to approve or reject a deployment only through the overview Environments page. In 15.0, you can now approve or reject a pending deployment approval from the environment’s detail page.
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.21 and 1.22. This release brings full support for all of the Kubernetes-related features from those versions.
GitLab now includes a REST API to register and manage the agent for Kubernetes. You can view the details about your agents, register new agents, and manage agent tokens. This API supplements the existing GraphQL API. You can use the REST API to automate the full agent lifecycle.
Previously, the only way to set the deployment_tier for an Environment was to use the keyword in the .gitlab-ci.yml file. In 15.0, we have added an endpoint to the Environment API to set the tier.
The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.8 we enabled the agent server for Omnibus based installations. The feature has matured in the past few months, so we are now making the agent server enabled by default in the GitLab Helm chart as well to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.
Dependency Scanning now supports parsing of poetry.lock files. This allows users to scan Python dependencies for vulnerabilities when those dependencies are managed by the Poetry package manager.
You can now switch to Semgrep-based scanning for many languages in GitLab SAST.
Semgrep-based scanning brings significantly faster analysis, reduced usage of CI minutes, and more customizable scanning rules compared to existing language-specific analyzers.
As of GitLab 15.0, it supports C, Go, Java, JavaScript, Python, and TypeScript.
GitLab Container Scanning relies on information from its analyzers to report vulnerabilities. Ensuring that databases have the most up to date information is important to make sure scans are returning both accurate and timeline results.
GitLab provides our own advisory database, which sources additional information that may not be updated in common sources. These external sources are tracked and information is updated daily. GitLab now includes this information when the trivy analyzer used with in GitLab Container Scanning, to help ensure that the most comprehensive and up-to-date vulnerability data is available for identifying vulnerabilities.
These databases give you access to additional threat information identified by GitLab’s research team, even if that threat data has not yet been added to other public databases.
Git is at the heart of every GitLab project and one of Geo’s key capabilities is to replicate Git repositories to secondary sites. Every time a new project is created, Geo needs to replicate the repository as fast as possible.
In this release, we’ve optimized the underlying Git commands used by Geo. By using git clone instead of git fetch for initial git repository replication performance increased by 27%.
GitLab 15.0 includes Mattermost 6.6, whose newest release includes triggers and actions on channel messages and the general availability of Apps Framework. This version also includes security updates and an upgrade from earlier versions is recommended.
In GitLab 15.0, the new default version of PostgreSQL for new installs will be 13.6. Users currently on PostgreSQL 12 will stay on PostgreSQL 12, unless the user manually upgrades the PostgreSQL version. New installs can opt into PostgreSQL 12 during installation if desired.
Starting in Gitlab 15.0, when the version of PostgreSQL changes, postgresql and geo-postgresql services are automatically restarted. Restarting PostgreSQL services causes downtime, due to the temporary unavailability of the database for operations. While this restart is mandatory for proper functioning of the database services, you might want more control over when the PostgreSQL is restarted. For that purpose, you can choose to skip the automatic restarts as part of gitlab-ctl reconfigure and manually restart the services. Users can also skip automatic restarts as part of GitLab 15.0 upgrade.
Before this release, you could only follow or unfollow a GitLab user from their user profile. It was difficult to know if you were following a specific user unless you viewed the user’s profile.
In this release, thanks to Kev’s contribution, you can quickly follow and unfollow users through the user popup, no matter where you are in your GitLab workflow: in notes, issues, and more. This reduces the extra step of going to the user’s profile, and makes it easier to follow and unfollow other GitLab users.
GitLab now records additional audit events when changes are made to merge request settings. Specifically, audit events are now created when changes are made to:
Merge commit message template
Squash commit message template
Default description template for merge requests
Status checks being added, changed, or deleted
Merge method
Merge options
Squash commits when merging settings
Merge checks
Merge suggestions
These audit events can help you know that the settings and default configurations for your merge requests have been put in place correctly and that they have not been changed. You might need to know this to pass audits that require separation of duties.
If these templates or checks are changed, the audit events show you when your workflow was changed to a non-compliant state and the related information to that change. You can have a retrospective to understand the specific change, when it was made, and who was involved. You can then take any remedial action as needed or work with the teams that made the change.
External status checks are great for integrating with third-party systems, but they didn’t always properly communicate the state of the check. You might wait for pending to update, but the external check had failed and there was no way to communicate this.
You can now set an external status check to an explicit failed (or passed) state. Previously, external checks could only be in pass or pending state. The new failure state allows you to very clearly indicate that something needs to be done to allow the external check to pass.
We’ve changed the permissions necessary to create, edit, and delete milestones and iterations from the Developer to Reporter role.
This change better reflects the typical day-to-day Reporter responsibilities of managing and tracking planning timeboxes.
When setting up GitLab Workflow for VS Code, you must provide a token to authenticate to GitLab. This token authenticates you to your GitLab instance as a particular user for checking out code, seeing issues, reviewing merge requests, and more.
In GitLab Workflow 3.44, you can now use multiple tokens to authenticate to the same GitLab instance. This can be great for users who have both work and personal accounts, or accounts with separated duties.
We’ve also improved key storage for tokens, which will now be stored in VS Code’s SecretStorage, and is backed by your operating system keychain.
We’re also releasing GitLab Runner 15.0 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.
Instance Administrators can set a number of CI/CD limits in the Admin Area of their instance. It is hard for users without administrator access to know what the limits are, especially when pipelines are failing because they bump into limits they didn’t know existed.
Now the CI/CD related limits for the instance can be seen on the instance configuration page found at /help/instance_configuration. Thanks to @wwwjon for this contribution!
Previously, when using environments, only one keyword existed to specify that a job is executing a task that does not trigger a deployment, or create or stop an environment. This environment: action: prepare keyword was intended for jobs that assist in preparing an environment. However, there are many other deployment related tasks beyond preparing an environment, and users have overloaded the prepare keyword to perform these tasks. In 15.0, we have added two new keywords to execute tasks that require access to environment scope variables. In the .gitlab-ci.yaml file, you can now add a generic environment: action: access keyword for a broad set of use cases and environment: action: verify when specifically needing to verify the results during a deployment.
Previously, release note descriptions were empty when a release is created. With this update, when creating releases in the UI based on a tag, you can now easily include that tag’s message in the release notes. You can select the checkbox option in the UI to append the tag’s message to the release notes section of the release. This change makes it easier to incorporate important content such as a changelog or feature list into the published release.
Previously, when using the environment:on_stop keyword, only one job could be specified and run as part of closing an environment. In GitLab 15.0, you can now specify multiple jobs with the on_stop keyword in your .gitlab-ci.yaml file that run in parallel when closing an environment to enable more complex environment teardown procedures.
We have added a new endpoint for the Groups API that enables you to retrieve releases for all projects within a group. This allows users or consumers of the API to conveniently get a holistic view of releases at the group level. The endpoint supports sorting by created_at date and pagination.
If you use Terraform, you can use the module registry to store your infrastructure modules and streamline your developer experience. GitLab ships with a set of Terraform CI/CD templates that support all of the GitLab features out-of-the-box and can help even inexperienced Terraform users get started quickly.
Previously, if you used the Terraform module registry, you needed to authenticate to the registry as part of a custom CI job, even if you used the Terraform CI/CD templates. Thanks to community contributions from @willianpaixao and @terorie, the built-in Terraform template now automatically looks in the CI job to retrieve authorized Terraform modules from the registry.
Dependency Scanning can now identify the shortest dependency path for findings identified in your project. This is visible in the Evidence section when viewing details for a vulnerability, and in the Location column of the Dependency List page. This improvement makes it easier for users to triage the finding, and to determine the steps to resolve the vulnerability.
Schema validation makes GitLab analyzers and third-party integrations more reliable.
If you use the GitLab-managed CI/CD templates, you don’t have to take any action.
The analyzers used in your pipelines automatically update to the latest version.
If you use a custom template, or if you’ve pinned analyzer versions, you need to update your CI/CD job definition to either remove the pinned version or update to the latest major version.
All new bug fixes and features will now be released in the new analyzer major versions.
These improvements won’t be available in the deprecated analyzer versions because we don’t backport bug fixes and new features; see GitLab’s maintenance policy.
As required, security patches will be backported within the latest 3 minor GitLab releases.
The new versions of all analyzers are:
API Security: version 2
Container Scanning: version 5
Coverage-guided Fuzz Testing: version 3
Dependency Scanning: version 3
Dynamic Application Security Testing (DAST): version 3
Infrastructure as Code (IaC) Scanning: version 2
License Scanning: version 4
Secret Detection: version 4
Static Application Security Testing (SAST): version 3 for all analyzers, except version 4 for the gosec analyzer
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.0 release milestone. These updates bring additional coverage, bug fixes, and improvements.
Brakeman analyzer updated to version 5.2.2. See CHANGELOG for details.
Update handling of conditionals, reflection, and nil values
Add additional String methods for SQL injection check
Update parser for Ruby 3.1 support
Secrets analyzer updated. 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.
GitLab 15.0 now lists scan result policies in your project’s merge request approval settings area. You can view, in one location, all merge request approval rules that apply to the project, with scan result policies displayed next to the merge request approval rules.
In GitLab 15.0, the GitLab agent server (KAS), which is required to manage the GitLab agent for Kubernetes, is enabled by default. Enabling the GitLab agent server by default allows you to benefit from the GitLab agent for Kubernetes as an active in-cluster component for solving any GitLab ↔ Kubernetes integration tasks.
Elasticsearch 8 is the current version of Elasticsearch by Elastic. Previously, you could not use Elasticsearch 8 for Advanced Search. You had to use older versions instead. Starting in 15.0, you can use Elasticsearch 8 for Advanced Search.
If you use Elasticsearch 7.x, you must upgrade to GitLab 15.0 before upgrading to Elasticsearch 8.
If you use Elasticsearch 6.8, upgrade to any Elasticsearch 7.x version before upgrading to GitLab 15.0.
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 15.0.
Remove old Elasticsearch migrations. By removing old Elasticsearch migrations, it will be easier to perform Advanced Search migrations when upgrading GitLab in the future.
You must not have any deprecated (for example removed in GitLab 15.0) settings in /etc/gitlab/gitlab.rb, otherwise the upgrade will abort. You must remove those settings and run gitlab-ctl reconfigure before attempting the upgrade again.
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