The last part of reviewing a merge request is communicating the outcome. While approving was unambiguous, leaving comments was not. They required the author to read your comments, then determine if the comments were purely informational, or described needed changes. Now, when you complete your review, you can select from three options:

• Comment: Submit general feedback without explicitly approving.
• Approve: Submit feedback and approve the changes.
• Request changes: Submit feedback that should be addressed before merging.

The sidebar now shows the outcome of your review next to your name. Currently, ending your review with Request changes doesn’t block the merge request from being merged, but it provides extra context to other participants in the merge request.

You can leave feedback about the Request changes feature in our feedback issue.

In GitLab 16.9, we have released a series of improvements to the CI/CD variables user experience. We have improved the variables creation flow through changes including:

• Improved validation when variable values do not meet the requirements.
• Help text during variable creation.
• Allow resizing of the value field in the variables form.

Other improvements include a new, optional description field for group and project variables to assist with the management of variables. We have also made it easier to add or edit multiple variables, lowering the friction in the software development workflow and enabling developers to perform their job more efficiently.

Your feedback for these changes is always valued and appreciated.

Currently, to use the auto-cancel redundant pipeline feature, you must set jobs that can be cancelled as interruptible: true to determine whether or not a pipeline can be cancelled. But this only applies to jobs that are actively running when GitLab tries to cancel the pipeline. Any jobs that have not yet started (are in “pending” status) are also considered safe to cancel, regardless of their interruptible configuration.

This lack of flexibility hinders users who want more control over which exact jobs can be cancelled by the auto-cancel pipeline feature. To address this limitation, we are pleased to announce the introduction of the auto_cancel:on_new_commit keywords with more granular control over job cancellation. If the legacy behavior did not work for you, you now have the option to configure the pipeline to only cancel jobs that are explicitly set with interruptible: true, even if they haven’t started yet. You can also set jobs to never be automatically cancelled.