GitLab 13.9 is now available, fitting the platform with all sorts of pipeline enhancements, a couple of additional security features, and ways to get insight into other users’ activities.
The first feature release after the company announced its new tiering system, in which it dropped starter/bronze and unified naming for self-managed and hosted variants of the platform, has arrived with a noticeable focus on process automation. The latest version premieres a new YAML function !reference to allow the reuse of configurations in a CI/CD pipeline, even if the config is defined in another file, which wasn’t an option before.
To help with debugging pipelines, admins can enable an expanded view of their CI/CD configuration. The still experimental feature copies configuration normally imported via include statements, displays extended job configurations, and replaces YAML anchors with the linked configs to present a full picture of what’s happening in a pipeline.
Resource groups have been adjusted to support multi-project and parent-child pipelines as well, making sure only “one downstream deployment pipeline runs at a time” to safeguard these processes. Meanwhile it has also become easier to see if a test in the pipeline is flaky or has legitimately failed, as unit test reports now include information on how often jobs did not succeed on the default branch.
Other interesting additions available to all users are the option to “follow” others to track their activity, markdown links for feature flags, make requests for follow-up reviews, and configure GitLab Runner in a way that leverages GPUs. The latter should make the whole platform more interesting for compute heavy workloads like those to be found in machine learning projects.
Organisations subscribed to the ultimate tier were also given a few nice enhancements such as an aggregated view of the release metrics associated with a group’s projects, as well as coverage-guided fuzz testing for Python and JavaScript applications.
The update also accommodated the fact that more enterprises are starting to double down on container network policies, by adding a dashboard for corresponding security alerts. Via the threat monitoring module, policies can be configured to send their alerts to the new UI to help monitor scenarios in which traffic “cannot be blocked entirely without negatively impacting the business”.
System admins taking care of self-managed premium or ultimate versions of GitLab have the option of putting their installation into maintenance mode and making it read-only for non-administrative users when fixing issues. They now also have the option to set the replication factor of a Gitaly Cluster to something smaller than the actual number of cluster nodes, which should help with instances with large storage requirements.
The GitLab team has also advanced its Pages support for GitLab on Kubernetes that was introduced in v13.8. The current iteration adds access control to make Pages only available to members of a project if needed. The GitLab chart has been changed to reflect that and now comes with labelling capabilities for all objects, ways to enable proxy protocol support, and updated redis and gitlab-explorer dependencies (6.0.10 and 10 respectively). Details are available in the release notes.