GitLab 15.5 released with GitLab Cloud Seed and Autocomplete suggestions
GitLab 15.5 released with GitLab Cloud Seed, Autocomplete suggestions in the Content Editor, Error Tracking Open Beta, Operational Container Scanning and much more!
These are just a few highlights from the 50+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 153 contributions they provided to GitLab 15.5! 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.6 release kickoff video.
Anatoli’s contributions to gitlab-docs during this milestone include improving code quality, adding Ruby code coverage support, and squashing a bug related to launching GitPod.
Thank you Anatoli for all your contributions!
Your nominator had this to say: “It’s been excellent to have some engineering help from the wider community.” Agreed! Thank you Anatoli for all of your contributions.
Cloud Seed allows GitLab and Google Cloud customers to migrate to the cloud using a single platform, consolidating their tech stack without slowing down their cloud adoption process.
Cloud Seed is built into the GitLab web UI and leverages CI/CD pipeline capabilities. It is specifically tailored to offer a frictionless developer experience for consuming Google Cloud services, supporting Service Accounts, Cloud Run, and Cloud SQL.
To develop this capability, GitLab worked with Google Cloud to build best-in-class experiences to simplify, automate and thus accelerate cloud resource provisioning, deployment automation and configuration. Google Cloud and GitLab worked together in an open-source model to make Cloud Seed available for paid and free users.
Cloud Seed’s easy-to-use and accessible format drives organic cloud adoption amongst users. Since it is a frictionless, open-source tool, developers and product teams can consume the Google Cloud services complementing its leadership’s cloud adoption efforts leading to an organic company-wide shift. As a result, GitLab is seeing increased bottom-up adoption of cloud services.
GitLab Flavored Markdown provides convenient shortcuts for referencing GitLab-specific items like users, issues, epics, and even emojis in your content. For example, you can type #35266 to link to that issue or :thumb to see a list of thumb emojis. Now when you use the Content Editor, you get access to the same powerful autocomplete suggestions.
GitLab now supports editing scan execution policies through the UI in Rule Mode in addition to the Yaml Mode that was available previously. This new visual editor makes it easy to construct a policy, even for non-technical users. Policies can be used to require security scans to run on a schedule or as part of a project pipeline. To get started, have a Project Owner link an associated security policy project on the Security & Compliance > Policies page.
On accounts with two-factor authentication (2FA) enabled, bad actors that enter correct usernames and passwords must still enter a
correct one-time password (OTP) to access the account. However, users would not know incorrect codes are being entered.
Now users are immediately sent an email when an incorrect OTP is entered, improving security by
notifying them that their account might be compromised.
In GitLab 15.5, we are re-enabling GitLab integrated error tracking for GitLab.com in Open Beta. We’ve reworked the architecture so it uses our new Observability backend, leveraging the ClickHouse database as a unified data store. This improvement will enable scaling and a more performant system for the user.
In addition, this sets the groundwork to have errors in the same database as other observability data such as metrics, traces, and logs. We want to allow users to see errors on the same dashboard as other observability data, and enable them to be embedded into issues and incidents.
You can now search the list of environments in the Environments page by name. Previously, there was no search functionality. This sometimes required you to scroll through many pages to find a specific environment and its latest deployment. Now you can easily find an environment by typing in the name into the search bar. Please note you can search for an exact or partial match of the environment name. Wildcards are not yet supported.
GitLab now officially supports vulnerability scanning of container images in operational or production Kubernetes environments. You can set up scanning either through the configuration file for your GitLab Agent for Kubernetes or by creating a scan execution policy to require scans to run on a regular cadence.
Results are displayed both on the project’s Vulnerability Report page under the Operational Vulnerabilities tab and also on the Infrastructure > Kubernetes clusters > Agent page under the Security tab. To get started, make sure you have installed the GitLab Agent for Kubernetes and that a scan cadence is defined either in the agent configuration file or in a scan execution policy.
We added a new Projects API endpoint that returns a list of groups to which you can transfer the specified project. Previously, you could select which group to transfer a project to from the dropdown list, which didn’t include groups made available through group sharing. Now, the new endpoint ensures that these groups are included too.
Now you can include these additional relationships in an import if you require them, which slows down the import
but includes more information. To import additional relationships, go to the GitHub import page and select appropriate
checkboxes under Advanced import settings.
For more information on related features available in GitLab 15.5, see:
Previously, a user’s commit email could be modified only in the UI. Now, administrators can use the Users API to modify the commit email and perform this as a bulk action.
Previously, if there were changes to group members’ SAML or SCIM identifier (also known as the NameID), the only way to update it was by having users unlink and manually re-link their GitLab and SSO accounts. Now, group owners can update the extern_uid field in GitLab for both SAML and SCIM identities to match the SSO identifier using a new endpoint in the groups API.
Imagine you need a quick view of issues in the current milestone which are at risk. We’ve taken issue health status to the next level, and with this improvement, users can now filter issues that have a specific health status.
Since the release of linked epics in 15.0, you could show blocking relationships among epics. With this additional improvement, you can now view that blocking relationship from the roadmaps view.
Anything can happen when you’re writing long-form content in a web browser. An accidental click could close your tab, your browser could crash, or your computer could run out of battery. In many areas of GitLab, content you haven’t posted is saved locally to prevent data loss. You can see this in action when commenting on issues and merge requests. Now you can rest a little easier knowing unsaved changes to wiki pages are preserved in the same way.
In the group runners list, you can now view all shared runners, runners from parent groups, and runners you administer. Previously, you could only view the runners you administer. This change provides a more comprehensive overview of group runners.
Since GitLab 14.4 you can limit the access scope of the CI/CD job token for a more secure CI_JOB_TOKEN workflow. If you wanted to determine if the setting was enabled in a project though, the only option was to manually go into the project’s settings. Starting in GitLab 15.5, you can check the response from the /jobs, /deployments and /environments API endpoints and programmatically verify the status of the setting.
In past releases, there was no easy way to configure a pipeline that refers to a release or to release notes associated with a tag. Now, you can refer to this information using two predefined environment variables: $CI_COMMIT_TAG_MESSAGE and $CI_RELEASE_DESCRIPTION.
The U.S. Government requires some GitLab customers to use FIPS (Federal Information Processing Standards) compliant software. You can now use the agent for Kubernetes on FIPS-enabled GitLab installations. This release also adds FIPS-compliant agent images that you can install on your clusters.
Previously, some outdated jobs could be manually started or retried even when Skip outdated deployment jobs is enabled. We have updated the logic for this setting to check the deployment status when a job starts. The job does not execute if the deployment job is outdated due to a more recent deployment. This check ensures that outdated deployment jobs are not accidentally started, overwriting more recent code changes in production.
In this milestone we added the ability to update a release using the Release CLI. You can use this to automate releases by updating any of the release attributes directly from the .gitlab-ci.yml file, and leveraging the CI/CD pipeline to do so.
GitLab Dependency Scanning now uses a new method of detecting Go dependencies that is more accurate than the previous method and allows users to scan the correct version of the dependencies that are actually used by the application.
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.5 release milestone. These updates bring additional coverage, bug fixes, and improvements.
Brakeman analyzer updated to fix a crash in False Positive Detection. See CHANGELOG for details.
CodeClimate analyzer updated to version 0.87.0. See CHANGELOG for details.
Kics analyzer updated to add additional rules, fix bugs, and update to kics version 1.6.0. See CHANGELOG for details.
PMD-Apex analyzer updated to version 6.49.0. See CHANGELOG for details.
Secrets analyzer updated to Gitleaks version 8.12.0. See CHANGELOG for details.
Security Code Scan analyzer updated to version 5.6.7. See CHANGELOG for details.
Semgrep analyzer updated to version 0.115.0. See CHANGELOG for details.
Update GitLab-managed rules to remove false positive results for:
Java SQL injection
C# LDAP injection
C# XPath injection
Fix a problem where Semgrep-based C# scanning created duplicate findings instead of combining them with Security Code Scan-based scan results.
SpotBugs analyzer updated to version 4.7.2. 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.
With this release, Geo supports replication and verification of Incident Metric Images. This protects against loss of this data during failover if Geo is used as part of a disaster recovery strategy.
This release improves code search quality for Advanced Search to bring it closer to the local IDE experience. You can now expect more relevant results for full tokens and some partial tokens as well as better matching for search terms with special characters.
GitLab administrators can now use the Admin Area to disable users’ permission to create top-level groups. Previously, administrators with access to the instance’s file system could change this setting only in the gitlab.rb file.
You can now import GitHub project image resources and other attachment types from release notes and comments.
The attachments are added to GitLab and their links are updated to new GitLab URLs.
Attachments aren’t imported by default because it can be a time intensive operation. To import them, go to the
GitHub import page, and select Import Markdown attachments under Advanced import settings when importing using
the GitLab UI.
We continue to improve the GitHub project importer by adding more metadata to the migrated projects. With added
pull request events history, the following pull request events
can be imported from GitHub and become part of a merge request’s metadata:
Closed or reopened.
Labeled or unlabeled.
Review requested or review request removed.
Assigned or unassigned.
Edited.
With added issue events history, the following issue events
can be imported from GitHub and become part of an issue’s metadata:
Closed or reopened.
Labeled or unlabeled.
Milestone added or removed.
Cross-referenced.
Assigned or unassigned.
Renamed.
Because importing pull request and issue events can take a long time, they aren’t imported by default. To import them,
go to the GitHub import page, and select Import issue and pull request events under Advanced import settings
when importing using the GitLab UI.
Prior to this release, API calls to retrieve personal access tokens (PATs) were relatively basic. Now, you can filter results on many properties and link filters together
to do complex filtering on parameters such as:
When a token was last used.
If a token is revoked.
A token’s name.
These new API filters for PATs provide users and administrators more useful results from the PAT API.
You can now add dates and labels to a task to better reflect additional context related to the task. You can filter tasks by their labels or sort tasks by due date in a project, group, or dashboard issue list.
Following the recent release of the new DORA Insights custom reporting, we have added a pre-defined report to the default insights configuration file. The new report visualizes the performance of the four DORA metrics over the past 180 days, aggregated by month and day.
This report helps you learn the DORA framework, understand how to use the metrics, and see how they perform over time on real data.
The Developer Certificate of Origin (DCO) is a per-commit sign-off made by a contributor stating that they have the right to submit the code to the project. By signing off on a commit, the contributor agrees to the terms published at developercertificate.org.
Now, you can easily enforce this Developer Certificate via a per-project setting to prevent contributors from contributing code that violates your license. When enabled, all new commits must include such a certificate of origin in the form of a line in the commit message Signed-off-by:.
Bulk editing is a powerful and valuable feature when you need to visualize or manage large data sets. For administrators that manage a fleet of runners, the lack of a bulk delete option is a productivity drain and increases the operational overhead of maintaining runners. Now, in the Admin Area, you can select multiple runners and delete them at the same time. You can also select and delete a full page of runners at once.
For GitLab administrators or group owners, locating a specific runner’s owner can be very time-consuming in environments where many runners are in use at the group or project level. This problem is even more acute and impactful to the customer if the runner in question is not picking up jobs or critical production jobs are running slowly. The Admin Area and group runners page now include an owner column so you can quickly determine the owner of any runner in the environment at a glance.
We’re also releasing GitLab Runner 15.5 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.
You can now create annotated tags and add them to your releases in the Releases page. You can use annotated tags to provide downstream users and applications with additional information about a release.
If you use the GitLab agent for Kubernetes with GitLab CI/CD on GitLab SaaS, previously you couldn’t use kubectl exec, attach, or cp calls. GitLab now supports these calls on top of the SPDY protocol. You can now use kubectl exec, attach, or cp in your CI jobs.
In previous versions of GitLab, DAST API and API Fuzzing scans used a fixed internal port for communications between backend components. In some user configurations this caused a conflict with another configured service. In GitLab 15.5, you can use the DAST_API_API_PORT and FUZZAPI_API_PORT variables to configure the internal port number used by the scanners when it conflicts.
GitLab application security scans run in CI/CD pipelines.
By default, scan jobs only run in branch pipelines.
Now, you can also run scans in merge request (MR) pipelines by switching to the Latest version of the CI/CD templates instead of the Stable version.
This makes it easier to use security scanning if you design your CI/CD pipelines around MR events.
We plan to update the Stable templates with this change in GitLab 16.0.
Note that Latest templates can receive breaking changes in any release.
To learn more about Stable and Latest templates, see documentation on CI/CD template versioning.
In the 15.4 release post, we announced that the GitLab Logger will be used by default for the GitLab Helm Chart in 15.5. This implementation has been delayed to 15.6. For users who have custom log parsers in place, be aware that this will automatically wrap all logs from plaintext to structured JSON.
Cloud Native GitLab will replace alpine-certificates behaviors with gitlab-base. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern on gitlab-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 brief period.
The GitLab Helm Chart will have a new major version release before the next major GitLab version, separate from the next major version as a whole. We are not sure when this next Helm chart major version will be released, but it can be expected no sooner than 3 milestones, but it may be longer. This major Helm chart release will require downtime, as we incorporate large updates and require manual intervention for upgrade paths.
GitLab 15.5 includes Mattermost 7.3, with new role-based permissions system for Boards and the ability to create boards independently from channels, multiple Playbooks enhancements including a redesigned left-hand sidebar and run detail page, and much more. This version also includes security updates and upgrade from earlier versions is recommended.
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.5.
GitLab 15.5 automatically migrates the deactivate dormant users period application setting to a minimum of 90 days. This change enforces a minimum inactivity limit of 90 days before users are considered dormant and their accounts are automatically disabled. This minimum ensures a good user experience and compliance with GitLab billing policies. A recent change allowed this feature to set a configurable limit, but did not set the minimum threshold of 90 days.
A workaround is to direct GitLab Runners to the primary site. This can be done at the DNS level. Configure the traffic policy to direct all requests from the runner location for the unified URL to the primary site.
To be consistent with all other data types, the Container Registry replication now leverages the Geo self-service framework. This is a behind-the-scenes change that will make support and maintenance easier in the future. No action is needed from your part.
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