On January 18, 2024, GitLab 16.8 was released with the following features.
In addition, we want to thank all of our contributors, including this month's notable contributor.
Ted has made significant contributions removing old and unused code from our helper files and addressing other maintenance tasks. He was nominated by Kerri Miller, Staff Engineer at GitLab, who said, “It’s not always glamorous work, but it’s important work”.
Ted is a freelance software engineer, avid climber, and cat enthusiast based in Orange County.
Martin was nominated by Viktor Nagy, Product Manager at GitLab, who said, “He added many missing tests to the Auto Deploy jobs template and improved the agentk Helm chart documentation”.
Lee Tickett, Engineer at GitLab, added that he “has been joining community pairing sessions on Discord and collaborating closely with team members to contribute a heavily requested search enhancement for merge requests”.
Martin is an IT Architect at Deutsche Telekom MMS GmbH based in Dresden, Germany.
Helio was nominated by Hannah Sutor, Principal Product Manager at GitLab, who said, “he has pushed our entire team forward by proposing the ability to sign in using passkeys. Helio’s MR was closed, but his contribution was deep, thought provoking, and his questions and open discussion will make our Passwordless implementation better”.
Helio is a software engineer with passion for Ruby and OSS.
Thank you Ted, Martin, and Helio! 🙌
We’re thrilled to share that Workspaces are now generally available and ready to improve your developer efficiency!
By creating secure, on-demand remote development environments, you can reduce the time you spend managing dependencies and onboarding new developers and focus on delivering value faster. With our platform-agnostic approach, you can use your existing cloud infrastructure to host your workspaces and keep your data private and secure.
Since their introduction in GitLab 16.0, workspaces have received improvements to error handling and reconciliation, support for private projects and SSH connections, additional configuration options, and a new administrator interface. These improvements mean that workspaces are now more flexible, more resilient, and more easily managed at scale.
A typical software project relies on a variety of dependencies, which we call packages. Packages can be internally built and maintained, or sourced from a public repository. Based on our user research, we’ve learned that most projects use a 50/50 mix of public and private packages. Package installation order is very important, as using an incorrect package version can introduce breaking changes and security vulnerabilities into your pipelines.
Now you can add one external Java repository to your GitLab project. After adding it, when you install a package using the dependency proxy, GitLab first checks for the package in the project. If it’s not found, GitLab then attempts to pull the package from the external repository.
When a package is pulled from the external repository, it’s imported into the GitLab project. The next time that particular package is pulled, it’s pulled from GitLab and not the external repository. Even if the external repository is having connectivity issues and the package is present in the dependency proxy, pulling the package still works, making your pipelines faster and more reliable.
If the package changes in the external repository (for example, a user deletes a version and publishes a new one with different files) the dependency proxy detects it. It invalidates the package, so GitLab pulls the newer one. This ensures the correct packages are downloaded, and helps reduce security vulnerabilities.
We added a new DORA Performers score panel to the Value Streams Dashboard to visualize the status of the organization’s DevOps performance across different projects. This new visualization displays a breakdown of the DORA score (high, medium, or low) so that executives can understand the organization’s DevOps health top to bottom.
The four DORA metrics are available out-of-the-box in GitLab, and now with the new DORA scores organizations can compare their DevOps performance against industry benchmarks or peers. This benchmarking helps executives understand where they stand in relation to others, and identify best practices or areas where they might be lagging behind.
To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.
From GitLab 16.8, you can specify commands to generate configurations for the following services in the
gitlab.rb file so that plaintext passwords are not exposed:
This means plaintext passwords for Redis no longer need to be stored in gitlab.rb.
To ensure all changes are reviewed and approved, it’s common to remove all approvals when new commits are added to a merge request. However, rebases also unnecessarily invalidated existing approvals, even if the rebase introduced no new changes, requiring authors to seek re-approval.
Merge request approvals now align to a git-patch-id. It’s a reasonably stable and reasonably unique identifier that enables smarter decisions about resetting approvals. By comparing the patch-id before and after the rebase, we can determine if new changes were introduced that should reset approvals and require a review.
If you have feedback about your experiences with resets now, let us know in issue #435870.
Improved developer experience, onboarding, and security are driving more development toward cloud IDEs and on-demand development environments. However, these environments might contribute to increased infrastructure costs. You can already configure CPU and memory usage per project in your devfile.
Now you can also set CPU and memory usage per workspace. By configuring requests and limits at the GitLab agent level, you can prevent individual developers from using an excessive amount of cloud resources.
This release adds full support for Kubernetes version 1.28, released in August 2023. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
There are five new abilities available you can use to create custom roles:
Add these abilities, along with other pre-existing custom abilities, to any base role to create a custom role. Custom roles allow you to define granular roles that only give a user the abilities they need to do their jobs, and reduce unnecessary privilege escalation.
Streaming audit events have been extended to support filtering by sub-group or project at the group level, in addition to the existing support for event type filtering.
This additional filter will allow you to separate out events in your streams to send to different destinations, or to exclude irrelevant sub-groups/projects, ensuring you have the most actionable events for your team to monitor.
Our compliance center is becoming the central destination for understanding compliance posture and managing compliance frameworks. We’re moving framework management into a new tab in the compliance center, as well as adding more exciting capabilities:
Previously, you could configure only top-level group streaming audit events for AWS S3.
With GitLab 16.8, we’ve extended support for AWS S3 to instance-level streaming destinations.
One of several new settings added to scan result policies to aide in compliance enforcement of security policies, branch modification controls will limit the ability to circumvent policies by changing project-level settings.
For each existing or new scan result policy, you can enable Prevent branch modification to take effect for the branches defined within the policy to prevent users from deleting or unprotecting those branches.
For those using SAML SSO and SCIM for user account management in GitLab, you can now use SSO to meet the merge request authentication requirement over password-based authentication for approving merge requests.
This method ensures only authenticated users can approve a merge request for security and compliance, without having to use a separate password-based solution.
With this release, you can now view the entire hierarchy lineage of a work item instead of just the immediate parent.
Work items include:
We’re also releasing GitLab Runner 16.8 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.
The list of all changes is in the GitLab Runner CHANGELOG.
CI_MERGE_REQUEST_DESCRIPTION predefined variable, making the description easily accessible in all jobs. In GitLab 16.8 we tweaked the behavior to truncate CI_MERGE_REQUEST_DESCRIPTION at 2700 characters, because very large descriptions can cause runner errors. You can check if the description was truncated with the newly introduced CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED predefined variable, which is set to true when the description was truncated.Teams can now build, test, and deploy applications on Windows Server 2022.
SaaS runners on Windows allow you to increase your development teams’ velocity in building and deploying applications that require Windows in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.
Try it out today by using saas-windows-medium-amd64 as the tag in your .gitlab-ci.yml file.