Today, we are excited to introduce a dedicated Pipeline Editor, a deployment frequency dashboard, and several quality of life improvements that will make using GitLab every day even more enjoyable. These are just a few highlights from the 50+ improvements in this release.
The new Pipeline Editor makes CI/CD easy to use
Since its inception, the defining feature of GitLab CI/CD has been the .gitlab-ci.yml configuration file. Configuring pipelines as code means you can version control and collaborate on pipelines using the same interfaces you use for your application code. Additionally, GitLab's advanced syntax provides a high degree of customization for sophisticated and demanding CI/CD use cases. However, all of this power and flexibility comes with a fair bit of complexity. This is why our vision for CI/CD is to create a visual pipeline authoring experience, built-in to GitLab, that simplifies the complexity letting you quickly create and edit pipelines while still exposing advanced options when you need them.
Today, we’re pleased to introduce the first iteration of the Pipeline Editor. Starting in 13.8, you'll have a dedicated editor designed for CI/CD with some enhanced functionality such as built-in linting and configuration validation. A pipeline visualizer in the editor will show you what your pipelines will look like before you commit your changes. These capabilities allow new users to get started with GitLab CI/CD quickly and make experienced power users more efficient. This is just the beginning of what's in store for the Pipeline Editor. We can't wait for you to try it out so you can share your feedback, suggestions, and code contributions.
Improve your DevOps maturity with deployment frequency metrics
IT leaders and practitioners alike love DevOps. Developers and software engineers love that DevOps makes their job easier while IT leaders love that DevOps makes the business perform better. For several years, DORA, the DevOps Research and Assessment firm, has conducted primary research on the impact of DevOps in the enterprise. Their published results have shown that DevOps maturity leads to positive business outcomes like happier customers, greater market share, and increased revenue. Four metrics in particular, commonly known as the “DORA 4”, are highly correlated with business performance. These are deployment frequency, lead time for changes, time to restore service, and change failure rate.
We’ve heard from many of you that you want to measure these metrics so that you can improve them. However, instrumenting your systems to capture and report on these metrics can be difficult and time-consuming. We decided to build them into GitLab for you so you can focus on improving your DevOps maturity instead of instrumentation. Starting with GitLab 13.8 you can find deployment frequency charts in your CI/CD analytics. This is just the first of the DORA 4 metrics to come to GitLab. Our vision for the coming year will be to add the additional three metrics so you’ll be able to measure and optimize your DevOps practices.
A few small features to improve your quality of life
As GitLab gets better with every iteration sometimes the most exciting improvements aren’t the big new features, but the small UX improvements that take a tedious task and make it simple and easy. In this release, we’ve shipped several long-asked-for enhancements that we think you’ll enjoy such as the ability to:
These are just a few of many ways GitLab has been made better in this release. Read on to see more. And, if you'd like to preview what's coming in next month’s release, check out our Upcoming Releases page as well as our 13.9 release kick-off video.
Yogi has been an outstanding frontend community contributor and in GitLab’s recent hackathon, submitted over 30+ merge requests that helped fix long-standing bugs, align our UX and help our platform consistency. That is A LOT of MRs in an area we are working hard to make as many improvements as possible for our users!
Yogi is a fantastic great example of how community members can embrace and champion our values at GitLab through transparency, iteration, and collaboration. Thank you Yogi, we appreciate you!
GitLab CI/CD provides you with flexible options to support a variety of advanced pipeline use cases. Pipeline syntax can be verbose and sometimes complicated, especially for those who are new to GitLab CI/CD. In this release, we are proud to introduce our first iteration of the Pipeline Editor.
The editor makes the CI configuration authoring experience much easier for both novice and advanced users alike. The pipeline editor is a single solution that groups all the existing CI authoring features (and future ones) in a single location. The pipeline editor is the best place to go when configuring your pipeline.
In addition to the editing experience, it has additional features that help you author pipelines without extra manual steps. CI validation continuously checks your pipeline configuration and provides you with an indicator that your pipeline configuration is valid. The new Pipeline Visualizer provides you with a graphic representation of your pipeline configuration. The Lint tab validates your pipeline syntax and provides you with details about each job.
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.
In GitLab 13.8, we will allow group owners to bypass SSO enforcement to access to their owned top-level groups. This will allow group owners to modify SAML SSO settings and prevent group member lockout due to SAML SSO misconfiguration or changes in identity providers.
In GitLab 13.7, we introduced a webhook that is triggered when a new member is added to a group. In GitLab 13.8, the group member events webhook will also be triggered if the access level of a user has changed, the expiration date for user access has been updated, or a user has been removed from the group. With the addition of these events, the group member events webhook can be used to be aware of all changes made to group members without relying on API calls which put unnecessary performance load on your GitLab instance.
Regulated customers rely on GitLab’s CI/CD capabilities to define and automate their security and compliance jobs and processes for deploying changes to sensitive environments. They need to ensure they’re maintaining separation of duties between the teams writing code and the teams deploying that code and these jobs always run in sensitive environments.
In 13.8, you can now use predefined project variables in the include: section of your .gitlab-ci.yml file. This change is part of a bigger solution to bring better separation of duties control to your GitLab CI/CD pipelines.
When you enter / into a description or comment field, all available Quick Actions are now displayed in a scrollable list. Quick Actions are a great way to efficiently update data on an issue, merge request, or epic, and this small improvement helps them be more discoverable in the context in which they are used.
GitLab offers a variety of tools to help you monitor and operate your applications, but not all projects in GitLab are web applications. For example, if you are working on an NPM package, hosting configuration files, or using a Wiki-only project, you might find that the Operations features are not needed by your project.
In GitLab 13.8, you can now disable the Operations features on a project-by-project basis, which removes access to the features and hides the menu item from the left sidebar. The new configuration can be found in Settings > General under the Visibility, project features, permissions section. Configuring your project in this way ensures that only the features that you use and that your project supports are available and visible in the GitLab interface.
Code owner sections allow multiple teams to configure their own code owners independently in the same file. This helps when multiple teams are responsible for common parts of the code, by helping authors getting feedback from the right reviewers. However, when approval from Code Owners is required, this applies to all the sections meaning all teams need to approve, which can hold back changes from getting merged.
GitLab 13.8 introduces the ability to designate optional sections in your CODEOWNERS file. Simply prepend the section name with the caret ^ character and the section will be treated as optional. This means, related changes through merge requests will not require approval from designated owners. With optional sections, you may continue to designate responsible parties for various parts of the code while providing a more relaxed policy for parts of your project that may be updated often but don’t require stringent reviews.
It can be challenging to set rate limits for your application in such a way to allow requests from trusted sources while blocking malicious traffic. We have made several enhancements to make it easier to properly set rate limits. First, you can now test rate limit settings using a new dry run mode that checks requests against each rate limit and logs the results without actually blocking the client. This lets you fine-tune request throttle settings before enabling them in production.
When your CI jobs are retrieving a container image from a container registry, a lost network connection can result in hours of lost development time and can negatively impact time-sensitive product deployments. To address this resiliency problem, the GitLab Runner Docker executor now supports the use of multiple values for the pull_policy configuration, which is defined in the GitLab Runner config.toml file. You can use these values, or stacked image pull policies, to configure combinations of pull policies and mitigate the impact caused by lost connectivity. For example, if you configure pull_policy =["always", "if-not-present"], the pull policy will always pull the image. However, if the target container registry is not available, the GitLab Runner Docker executor will fall back and use the if-not-present policy, which means a local copy of the image will be used for that pipeline job.
We’re also releasing GitLab Runner 13.8 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
Previously, the rules keyword was limited in scope and only determined if a job should be included or excluded from pipelines. In this release, you can now decide if certain conditions are met and subsequently override variables in jobs, providing you with more flexibility when configuring your pipelines.
You can use your project’s Package Registry to publish and install NuGet packages. You simply add your project as a source using the NuGet CLI, Visual Studio, or the .NET CLI. For example, using the NuGet CLI you can run:
nuget source Add -Name <source_name>
-UserName <gitlab_username or deploy_token_username>
-Password <gitlab_personal_access_token or deploy_token>
This works great if you have a small number of projects. But if you have multiple projects nested within a group, you might quickly find yourself adding dozens or even hundreds of different sources. For large organizations with many teams, it’s common for a team to publish packages to their project’s Package Registry alongside the source code and pipelines. But, they also need to be able to easily install dependencies from other projects within their organization.
Moving forward, you can install packages from your group so you don’t have to remember which package lives in which project. Simply add your group as a source for NuGet packages and you can install any of the group’s packages.
nuget source Add -Name <source_name>
-UserName <gitlab_username or deploy_token_username>
-Password <gitlab_personal_access_token or deploy_token>
We hope this feature makes sharing dependencies between projects a little bit easier.
Used in conjunction with the new site validation feature, active DAST scans are now available for configuration in the on-demand DAST scanner profile. After validating a site for ownership, you can configure an active scan to run against the site. These scans include actual, destructive, malicious attacks against the site. Because of this, we recommend and encourage that you only use an active scan on staging and test sites that do not contain production data, where data loss is not a concern.
In the future, we will augment other analyzers missing vulnerability metadata and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.
GitLab sends email notifications when your pipeline succeeds, fails, or is fixed. In previous releases, these emails looked similar. This made it hard to tell the pipeline status without reading the entire body of the email. This release updates the subject line of these email notifications so you can determine pipeline status with a quick glance.
When managing your infrastructure with Terraform, you might create multiple state files, such as state files for each branch. To debug issues, you need an overview of the state files attached to your project, and various actions you can take for each state file. In previous versions of GitLab, managing Terraform state files required the API for tasks like releasing a state lock. We are now introducing a UI to list existing state files. It enables project maintainers to lock or unlock a state file, remove the state JSON, or to remove a state file entirely.
One Git repository can be compared to another by checksumming all refs of each repository. If both repositories have the same refs, and if both repositories pass an integrity check, then we can be confident that both repositories are the same. For example, this can be used to compare a backup of a repository against the source repository.
The new gitlab:git:checksum_projects rake task allows systems administrators to select a subset of projects by ID or loop through all projects, and output a checksum of the Git references that can be compared to a copy of the same project.
Patroni is a solution for
PostgreSQL high availability which also allows the
configuration of a highly available PostgreSQL standby cluster on a Geo
secondary. This configuration is important when a secondary is used as
part of a disaster recovery strategy because it allows systems
administrators to mirror the number of database nodes on the primary and
secondary. This means that after a failover, no additional database nodes need to be provisioned to regain high-availability.
In every release, we continue to make great strides in improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!
In GitLab 13.8, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.8 are:
With status updates, users can currently share a personalized status message and emoji with their team. We are now taking this one step further with a busy indicator. By marking yourself as Busy, your coworkers can easily see when you are unavailable for code reviews and other tasks. The Busy status will be displayed next to your name throughout the GitLab user interface.
A faster and easier way to migrate your GitLab Groups is on the way. Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files. In this release, we migrate only the Group object with basic fields. We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.
In GitLab 13.8, users created via SCIM or SAML will receive a welcome email that informs them that their account was created for use within their organization’s group. Future iterations will give group administrators more control over accounts that are provisioned by their SAML or SCIM integrations.
After completing development and verifying your product meets all requirements, it may be necessary to export the requirement status to allow for incorporation into a higher level requirements traceability analysis. With the introduction of the requirements export feature, this is now possible! Simply initiate the requirement export and they will be automatically sent to you in .CSV format, ready to import into other tools or provide to your customer.
This is the first iteration of this feature, so please provide feedback and follow along in the Requirements Export Epic.
When working to have your merge request reviewed, approved, and finally merged, it’s important to select the right people to perform those tasks. Asking for a review from people who can’t provide the approvals can slow down the process of delivering your contribution.
From GitLab 13.8 onwards, when selecting a reviewer for your merge request, you can see which approval rules that the user matches displayed right below the reviewer’s name.
When viewing a commit in GitLab, the merge requests containing the commit are linked. Finding the merge request that added the commit is very useful when you are trying to find the business and technical context of a change.
If you use squash or merge commits, merge request information was not previously included. GitLab 13.8 now includes merge request links for all commit types, ensuring you can find where a change was introduced.
Creating a Markdown file named _sidebar in the Wiki will use the contents of that file to generate a custom sidebar navigation menu for your project. Editing this file, however, was tricky as there was nowhere in the interface to open _sidebar again.
Thanks to a wonderful community contribution from GitLab user Frank Li, starting in GitLab 13.8 there is now an Edit sidebar button in the top right of the Wiki page. Clicking this button will automatically create the _sidebar file if it doesn’t already exist and open it in the page editor. With this quick access, it is more intuitive to create and easier to maintain your custom Wiki navigation.
Jupyter notebooks are documents that contain live code, equations, visualizations, and narrative text. They are widely used for data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and more. They are capable of using “rich output” to show an object’s rendered representation, such as HTML, JPEG, SVG, or LaTeX files. Previously, opening the notebook in Jupyter was the only way to read it with rich output.
GitLab 13.8 now shows rich output for Jupyter notebook content by default. This is an excellent way both to preview changes to your files as well as consume Jupyter notebook without ever having to leave GitLab.
You can use the allow_failure keyword to prevent failed jobs from causing an entire pipeline to fail. Previously, allow_failure only accepted boolean values of true or false but we’ve made improvements in this release, so now you can use the allow_failure keyword to look for specific script exit codes. This gives you more flexibility and control over your pipelines, preventing failures based on the exit codes.
Keeping the latest artifact from the most recent successful job is a useful default behavior but can also result in significant amounts of storage usage. This can cause an unexpected surge in disk space usage if you have pipelines that generate large artifacts. To improve storage consumption management, you can now disable this behavior for any project in the settings.
Coming up next, gitlab#276583 will allow you to entirely disable keeping the latest artifacts at the instance level.
Previously it was not possible to run pipelines for branches first, then switch to merge requests pipelines when the MR is created. Consequently, with some configurations, a push to a branch could result in duplicate pipelines if a merge request was already open on the branch: one pipeline on the branch and another for the merge request. Now you can use the new $CI_OPEN_MERGE_REQUESTS predefined environment variable in your CI configurations to switch from branch pipelines to MR pipelines at the right time, and prevent redundant pipelines.
API fuzz testing results are now shown in the Security Dashboard and
all other locations that security scanners show their results. You
can now triage API fuzz testing results, create issues for them, and
engage with your teams just like you can with other scanners.
We’re incredibly excited to bring these results out of the Tests
tab so that you can integrate API fuzz testing alongside other
security scanners and truly shift security left.
GitLab’s DAST has always had only a single template that isn’t versioned and is updated whenever we need to change things. This has proven difficult for users whose tests break after a template update. Starting in GitLab 13.8, we introduce a .latest version of the template. This template includes all template changes made between major releases, including breaking changes. This gives users a warning that changes are coming and enables them to test the changes for themselves before being forced to switch.
Breaking changes are brought into the stable template on the next major GitLab version. For non-breaking changes, these can be brought into the stable template after living in the latest template for a few releases. The speed at which the changes are incorporated into the stable template depends on a number of factors and takes into account feedback from users as they test the changes in the latest template.
Beginning in GitLab 13.8, users can validate that they own or have permission to test the domains added as a site profile. By adding a text file with a project- and site-specific string to their site, users can validate ownership of the domains. The validation process unlocks the ability to run active DAST scans against the domain. Since active DAST scans include actual attacks against the site, site validation provides a level of assurance that users can’t accidentally run an active scan against a site where they could cause data loss or damage. Because of this, any site profile that uses a domain that isn’t validated is only allowed to use scanner profiles that use a passive scanning mode.
If you use Terraform to set up GitLab, we are happy to announce version 3.4.0 of the GitLab Terraform Provider. In the past months, the provider received support of project mirroring, group sharing, project approval rules, and instance-level CI variables, besides many smaller enhancements and a few bug fixes.
Processing incidents during a fire-fight requires responders to coordinate across multiple tools to evaluate different data sources. Collecting and assessing metrics, logs, and traces - and sharing these with a response team - is time-consuming and challenging. We’ve streamlined this workflow by providing drag-and-drop uploads for these screenshots in a new Metrics tab on incidents. Aggregate and centrally locate all your screenshots of metrics so your team can quickly access and reference important charts.
Advanced Search can scale from small personal instances all the way up to GitLab.com. On some of the largest instances, however, search can slow down as the size of the index grows, and the number of permissions needing to be checked.
In GitLab 13.8 we have split out issues into their own index, making Advanced Search faster for larger instances. We have also simplified the method of permissions checks, further improving performance.
This update will apply automatically, without a need to conduct a manual reindex. The process takes less than 2 hours, however, there will be a delay in indexing new content while this completes.
In GitLab 13.8, we added the ability to specify multiple virtual storages within our Praefect chart. If you have enabled Praefect, which is off by default and not yet GA, please note that the StatefulSet name for Gitaly will now include the virtual storage name. Because of this name change, any existing Praefect-managed Gitaly StatefulSet names (and, therefore, their associated PersistentVolumeClaims) will change as well, leading to repository data appearing to be lost. In this case, repository data can be restored by following the managing persistent volumes documentation, which provides guidance on reconnecting existing PersistentVolumeClaims to previous PersistentVolumes.
For new deprecations and the complete list of all features that are currently deprecated, see GitLab documentation.
Default DAST spider begin crawling at target URL
In GitLab 14.0, DAST will remove the current method of resetting the scan to the hostname when starting to spider. Previous to GitLab 14.0, the spider would not begin at the specified target path for the URL but would instead reset the URL to begin crawling at the host root. In GitLab 14.0, the default for the new variable DAST_SPIDER_START_AT_HOST will be changed to false to better support users’ intention of beginning spidering and scanning at the specified target URL, rather than the host root URL. In addition to starting to crawl the specified URL, this will have an added benefit that scans could take less time, if the specified path does not contain links to the entire site. This will enable easier scanning of smaller sections of an application, rather than the entire app being crawled at every scan.
Jun 22, 2021
Removed direct link to Opsgenie
We have enabled a deeper integration with Opsgenie and other alerting tools through HTTP endpoint integrations so you can see alerts within the GitLab interface. As a result, the previous link to Opsgenie in the alerts list has been deprecated in this release.
January 22, 2021
Please check out the changelog to see all the named changes: