GitLab 13.8 is now available and treats users to a pipeline editor, additional validation helpers, and the capability to comment on issues via email, reducing the need to switch context.

While most experts probably are content working in the pipeline configuration file, the newly introduced pipeline editor is meant to simplify things for new users and those working to describe especially complex pipelines. Its first iteration comes in the form of a new page in the GitLab UI which groups an editor, the CI lint tool, and a visualisation component as well as some commit functionality for easy access.

CI lint could previously be found under jobs. The new location is meant to integrate better into the config writing workflow, so that devs can validate syntax before committing changes. The editor itself also comes with a validation component which indicates the CI configuration’s status just above the editing window. Users who feel like they’d benefit from some sort of graphic representation of their pipeline can now find one under “Visualize”. This first version shows stages and jobs, marking out dependencies between components along the way.

The pipeline editor is enabled by default. Admins who’d like to keep it hidden can however disable the component via the GitLab Rails console.

Other than that the GitLab team has been busy realising some long-standing community requests, such as allowing maintainers to comment on issues directly via email, or a more intuitive way to comment on multiple lines at once. Instead of adjusting line numbers after posting, users can now drag the comment marker across the segment in question to give feedback on longer code additions. 

Rebasing has become easier as well, meaning devs who want to reapply commits on top of a new one can just type /rebase in the comment window. Users of the merge request widget meanwhile gained the ability to download build artifacts directly for testing purposes.

In a bid to give teams using Kubernetes deployment of GitLab the same options as their Omnibus using colleagues, GitLab’s devs have added support for static-site hosting service GitLab Pages in 13.8, making it more of an option for some cloud native companies.

Starting with the current release, GitLab has begun adding the DORA 4 metrics deployment frequency, lead time for changes, time to restore service, and change failure rate to its ultimate and gold tiers. They are meant to give organisations an idea of the level of maturity of their DevOps practice and give some indication as to what can be improved. GitLab 13.8 therefore comes with a display of deployment frequency charts in the CI/CD analytics area of the tool. The remaining metrics are planned to join later in the year.

[Edit] First feedback suggests updating to 13.8 isn’t the best idea if you’re working with an Omnibus package and are relying on GitLab Pages, since many have seen their Pages rendered unusable after flipping the switch. Hopefully the next patch release will fix the issue.

[Edit] 13.8.1 is available now, patching, amongst other things, the auth settings bug responsible for the Pages problems.