GitLab 12.7 dropped perfectly on schedule this week, providing users of the repository management turned DevOps platform with improved pipelines and Windows devs with a shared runners beta.
The most highlighted feature of the release (which unfortunately isn’t available on the core or free tier) are parent-child pipelines, in which pipelines can be split into elements organised in a parent-child relationship. A compartmentalisation like this is meant to make complex workflows easier to digest and offer an option for parallelisation. With the new release, child pipelines can be defined in separate YAML files and make use of code present in other pipelines via include. The single elements are triggered through .gitlab-ci.yml which stays the primary entry point.
Teams looking for less concurrency instead, can now make use of the new resource group attribute. Once it is defined for a job in the YAML file, “job executions are mutually exclusive across different pipelines for the same project”. Should multiple jobs of a group have been enqueued at the same time, the projects Runner will choose and run one, while the others have to wait.
Windows shared runners are now available on GitLab.com, in beta for now. Previously GitLab shared runners, managed by GitLab, were only available for Linux. The company said the GitLab-hosted Windows Shared Runners are “pre-configured with various software packages such as the Chocolately package manager for Windows, Visual Studio 2019 Build Tools, Microsoft .Net Framework, to name a few.” It’s worth noting that pricing for Windows Shared Runners will initially match that for Linux, but over time are likely to attract separate higher pricing than Linux minutes.
Other enhancements available to all users include information on the target and time of deployment for all merge requests and a way of sharing groups with other groups. GitLab also improved searches by allowing an “is not” operator, which allows excluding certain results during filtering operations.
Paying customers meanwhile will also find themselves with new features such as code review analytics and audit events for releases at their hands. A full list of changes can be found on the official website.
Ahead of the actual release, GitLab informed its users about three changes to Epics, which the firm claims will help teams “enhance their workflow”. First up is the ability to create an issue directly from an epic. This should make it easier to create relevant issues, and break down a project into “more digestible vertical feature slices”. The firm goes so far as to describe this as a “quality of life improvement”, as users will no longer “lose” issues if they forget to manually relate them.
Secondup, is the addition of “weight and progress” on roadmaps, which should make it easier to understand the completion progress of each item. Again, it removes a discrete manual step, ie calculating progress and working out if goals are attainable. The third addition is the ability to expand epics on roadmaps, to view hierarchy. Or put another way, child epics can be viewed under parent epics on the roadmap.
This lays the ground for more work on dependency mapping, and surfacing dependencies on the roadmap in future releases, the firm said.