The CI lint tool validates your pipeline syntax and provides you with some details about each job. Previously, CI lint was located on the jobs page which was difficult to find and access. In this release, accessing this tool is much easier than before because it is now included as a part of the new Pipeline Editor. With this improvement, you can easily use CI lint while editing your configuration and quickly validate that your syntax is what you want before committing the changes.
Previously, to validate your CI/CD configuration, you had to navigate to the CI lint page or commit your changes and look for any errors. In this release, we’ve added verification in the pipeline editor itself. It continuously checks your pipeline configuration before writing your
.gitlab-ci.yml file and provides you with an indicator that your configuration is valid. This saves you time and effort that could otherwise be spent optimizing your pipeline.
A complex CI configuration can be difficult to understand as a developer, especially when trying to predict how your pipeline might behave (or misbehave). Without a visual aid, it is challenging to form a mental image of the relationships between all of the jobs and determine how they are interconnected. In our first iteration of a pipeline visualization, you can now see a graphic representation of your
.gitlab-ci.yml configuration to better understand and predict how your pipelines will perform.
Knowing and monitoring deployment frequency is a starting point for organizations adopting DevOps. We are proud to introduce deployment frequency charts at the project level so that you and your development teams can monitor the efficiency of deployments over time, find bottlenecks, and make improvements when necessary. This is the first of the DORA metrics that we are making available within GitLab out of the box.
To more efficiently integrate GitLab into your email workflows, each issue now has a unique email address. Emailing an issue creates a new comment on your behalf. You can now say goodbye to manually copying email content and attachments into your GitLab issues.
Commenting on a single line is great for simple kinds of code review feedback, but often a comment addresses multiple lines in the diff. For instance, a portion of a logic block, a paragraph of prose, or an entire function. This forces users to choose a single line to provide feedback, but the feedback refers to other portions of the file.
Previously, users could select multiple lines after posting a comment by adjusting line numbers up and down from the original comment point. Now, users can click at the beginning of a line and drag the comment marker across multiple lines to highlight and reference multiple lines when leaving feedback in a merge request.
In this release, we added the ability to download build artifacts directly from the MR widget. This is especially useful for mobile development. An example of this is where users want to test an Android package of a specific build created on a physical device or an emulator. You can now access these artifacts directly from the merge request widget without having to find the artifacts buried in the pipeline view.
When you’re reviewing the results of a Merge Request’s pipeline execution, there may be test failures to investigate further. It’s often hard to validate whether a test failure is accurate and needs to be fixed, or if it’s simply a flaky test that can be ignored. Figuring this out can be even more difficult when you’re not dealing with a brand new test failure.
The first minimal viable change for the repeat failed test counter will provide you a count of how often a test has failed in previous pipelines on the Test Summary Merge Request Widget. We are requesting feedback from the wider community in this issue to understand what we can improve in future iterations of this feature.
Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.
Earlier this year GitLab committed to moving 18 features to our open source core product. With this release of GitLab we’ve completed the work to move Deploy Boards to Core. We’re excited about bringing these features to more users and seeing what use cases and workflows you’re able to use them for.
Rebase is a Git command used to reapply commits on top of a new commit. In practice, this means reapplying commits from a feature branch on top of the latest version of the target branch (e.g.
main). In this way, it is possible to bring the feature branch up to date and resolve any conflicts without using a merge commit resulting in a simpler linear Git history.
GitLab 13.8 brings the ability to execute the rebase quick action in merge requests, allowing you to quickly invoke the rebase Git utility.
On a merge request comment, type
/rebase and click the Comment button. It’s that simple.
Users want the highest possible levels of fault tolerance in highly-available Gitaly Clusters. This release introduces distributed reads for Gitaly Clusters. Instead of always reading from the primary node, Gitaly now automatically distributes read requests to any up-to-date node in the cluster. Distributing requests maximizes both performance and value proposition by giving your users access to all the computing resources provisioned in the cluster. Users also want to prevent performance degradation from noisy-neighbor repositories on the same node. This issue is particularly important for large and busy monorepos, where thousands of engineers and CI pipelines simultaneously access the same Git repository. By horizontally distributing read requests, Gitaly Clusters improve performance across all repositories in the cluster. To read more about Gitaly Clusters and how we’ve developed our own traffic management solution for Gitaly Cluster, see our blog post, Meet Praefect: The traffic manager making your Git data highly available.
GitLab Pages is a popular static-site hosting service built into GitLab, and we are excited to announce that it is now available for GitLab instances running on Kubernetes. Pages was one of the last remaining feature gaps compared to an Omnibus deployment.
Many teams use boards to manage issues during an iteration. In 13.6, we added support for filtering issues on a board to a specific Iteration, but it is cumbersome to remember to apply that filter every time you go to your board.
In this release, we’ve added the ability to scope your board to the currently active iteration.