Web IDE Beta enabled by default on self-managed
Web IDE Beta enabled by default on self-managed
The Web IDE Beta brings powerful new capabilities and dramatically improved performance to the web-based code editor. The Web IDE Beta has been available for self-managed instances since GitLab 15.7, but was disabled behind a feature flag.
From GitLab 15.11, the Web IDE Beta is now the default editor for all self-managed instances. You can opt out of the Web IDE Beta any time in your user preferences.
Award achievements to users
Award achievements to users
Using achievements, users can now acknowledge the accomplishments of others and reward the effort and skill that they have demonstrated. You can now receive achievements for your contributions on GitLab, and display them on your user profile. An achievement consists of a name, a description and an avatar. Users with the Maintainer or Owner role can create custom achievements, award them to users meeting the achievement criteria, and revoke them if they no longer meet the criteria. Up to three of your most recent achievements will display underneath your profile image on your user profile page. If you prefer not to display achievements on your profile, you can opt out in the user profile settings.
In 15.11, we are releasing a Beta of this capability behind a feature flag. If you want to try it out on self-managed GitLab, ask your administrator to enable it. For GitLab.com, please request access in the feedback issue 405153.
We hope that this change will increase productivity and engagement in organizations, and motivate team members to showcase their skills and accomplishments. Please share your experiences in issue 405153.
Google Play Store integration
Google Play Store integration
From GitLab 15.11, you can configure and validate your projects with Google Play Store credentials. You can then use those credentials in CI/CD pipelines to automate releases to the Google Play Store.
To record your experiences with the Google Play Store integration, see this feedback issue.
Manage project compliance frameworks report at group level
Manage project compliance frameworks report at group level
Prior to GitLab 15.11, if you wanted to add or remove a compliance framework from a project, you needed to go to each project individually to manage which framework was associated with the project. When managing more than a few projects, this process was tedious and inefficient.
Now, you can manage which compliance frameworks are applied to your projects at the group level, significantly reducing the amount of time needed to make sure your projects are adhering to the regulations and standards you are measured against.
In GitLab 15.10, you could view all the projects in your group and see which ones had compliance frameworks applied to them. In GitLab 15.11, you can add or remove compliance frameworks directly from the compliance frameworks report.
Vulnerability dismissal reasons
Vulnerability dismissal reasons
In previous releases, you had to manually add a comment to specify why a vulnerability was dismissed. In GitLab 15.11, you can add a reason for dismissing a vulnerability to the Vulnerability Report. Now you can quickly and consistently track why vulnerabilities were dismissed.
This feature is only available on GitLab.com. Support for self-managed instances is tracked in this issue.
Value Streams Dashboard released in Beta
Value Streams Dashboard released in Beta
This new dashboard provides strategic insights into metrics that help decision makers to identify trends and patterns to optimize software delivery. The Beta release is focused on measuring software development (DORA4) and the flow of value delivery (Value Stream Analytics) across projects and groups.
Organizations can use the Value Streams Dashboard to identify workflow inefficiencies and opportunities for improvements by benchmarking key DevSecOps metrics.
The Value Streams Dashboard offers visibility across every step of the software development lifecycle, without needing to buy or maintain a third-party tool.
Rerun downstream pipeline trigger jobs
Rerun downstream pipeline trigger jobs
Previously, if you needed to trigger a rerun of an entire downstream pipeline, you had to rerun the full upstream pipeline. This could be a time-consuming and inefficient process, especially if the upstream pipeline has many jobs or other downstream pipelines.
In this release, we’ve added the ability to rerun just the downstream pipeline, without having to re-run the entire parent pipeline, by selecting Run again on the trigger job. The newly triggered downstream pipeline replaces the original downstream pipeline in the pipeline graph. This will save you time and resources when you want just the downstream pipeline to run again.
Define inputs for included CI/CD configuration
Define inputs for included CI/CD configuration
Previously, if you wanted to change the behavior of included CI/CD configuration, like a CI/CD template, you may have used global CI/CD variables. However, using global variables applies to the entire pipeline, not just the included configuration, which was not always desirable.
This release adds the ability to declare mandatory or optional input parameters for each includable configuration file. These input parameters replace the need for global variables and are scoped to the included configuration only, having no impact on the rest of the pipeline. This allows you to build more robust and isolated CI/CD templates, as well as declare and enforce constraints. Learn how to use CI interpolation in this example repo.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback