GitLab has made 13.4 available for download and has fitted the DevOps platform with additional security features and a revamp of the Instance Security Dashboard ultimate/gold users have grown familiar with.
The company also made good on its promise to open-source more capabilities by, for example, moving the Related Issues function into the Core tier.
The most apparent change in the new version is something only ultimate/gold users will get to see. Instead of cramming together everything from vulnerabilities to metrics visualisations in one page, the team has set up a Security Center with a menu structure to separate the security dashboard from vulnerability reporting, and settings.
Of course, having everything in one place is always useful if you want to get a quick overview of your system’s security state. However GitLab’s devs felt that it got harder to expand some of the functions in the old setup, which is why everything has its own page now, allowing for more room to display details and giving GitLab a foundation for adding to each area.
Ultimate/gold tier users now get alerts presented in the environments page and there is an API fuzz testing capability for them to test. Given OpenAPI v2 specifications or HAR files of an app, the latter generates random inputs to find issues with web apps and APIs other scanning mechanisms might miss. Those wanting to use GitLab and Kubernetes in combination but couldn’t thanks to the integration’s need for a cluster to be open to the internet can now try a Kubernetes Agent. The tool is still in its early stages and therefore doesn’t support things like deploy boards, but at least it runs inside a cluster, making it a bit more enterprise-compatible.
With version 13.4, premium/silver and ultimate/gold users get more support in setting up a secure environment through a new secrets syntax in the .gitlab-ci.yml file meant to facilitate configuration and use of HashiCorp’s secret management tool Vault with GitLab. It also accommodates for the fact that some not so DevOps-y enterprises separate development and deployment by giving teams the option to let users without maintainer access deploy code. Another addition provides users with a .csv file of code coverage data which at some point will be plottable in the software to help visualise the developing coverage over time.
As usual, the monthly update brings a variety of improvements available to all tiers as well. This time, these include some alert related enhancements such as insight into an alert’s payload for incidents created from such warnings, and alert-specific references in GitLab’s Markdown. To make the generation of incidents easier, they have been added to the New Issue workflow.
Another focus area for the GitLab devs that all users can profit from were pipelines. Teams can now set up child pipelines in such a way that they can trigger their own child pipelines instead of having to define trigger jobs in a parent. While they were at it, GitLab reworked navigation between both pipeline classes so that it’s easier to get a grip on how they are connected and triggered. More insight is also the goal of some matrix jobs tweaking which now outputs “the relevant variable values that were used in that job” instead of a generic job name.
Other than that GitLab accounts can be connected to Atlassian Cloud ones so that Atlassian credentials can be used to sign into GitLab. The company has also decided to make its feature flag feature available to more people, which is why it can now be found in the starter tier. A move to core is planned for version 13.5.
Meanwhile the GitLab for JIRA app can now be used by everyone, as can the DVCS Connector, to get information about GitLab commits and merge requests displayed in JIRA, as well as the related issue feature.