Discover all-in-one software delivery.
Install JiHu GitLab →Install one package, run a complete solution.
By Use Case
Continuous integration (CI/CD) →Automate everything, accelerate deployment.
Source code management →Build the future with a shared history.
Auto DevOps →Adopt DevOps with a single commit.
DevSecOps →Integrate security, deliver faster continuously.
Agile development →Keep your methodology, gain functionality.
Visualize what works and optimize the rest.
GitOps →Simplify IT with DevOps-style automation.
By Organization Type
Small business →Get a DevOps platform that grows with you.
Enterprise →Adopt one platform for endless possibilities.
16.5
GitLab 16.5 released with compliance standards adherence reports and merge request target branch rules
Today, we are excited to announce the release of GitLab 16.5 with compliance standards adherence reports, merge request target branch rules, resolvable issue threads, fast-forward merge trains with semi-linear history, and much more!
These are just a few highlights from the 25+ improvements in this release. Read on to check out all of the great updates below.
To the wider GitLab community, thank you for the 170+ contributions you provided to GitLab 16.5! At GitLab, everyone can contribute and we couldn't have done it without you!
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 16.6 release kickoff video.
The Compliance Center now includes a new tab for the standards adherence report. This report initially includes a GitLab best practices standard, showing when the projects in your group are not meeting the requirements for the checks included in the standard. The three checks shown initially are:
- Approval rule exists to require at least 2 approvers on MRs
- Approval rule exists to disallow the MR author to merge
- Approval rule exists to disallow committers to the MR to merge
The report contains details on the status of each check on a per project basis. It will also show you when the check was last run, which standard the check applies to, and how to fix any failures or problems that might be shown on the report. Future iterations will add more checks and expand the scope to include more regulations and standards. Additionally, we will be adding improvements to group and filter the report, so you can focus on the projects or standards that matter most to your organization.
Some projects use multiple long-term branches for development, like develop and qa. In these projects, you might want to keep main as the default branch since it represents the production state of the project. However, development work expects merge requests to target develop or qa. Target branch rules help ensure merge requests target the appropriate branch for your project and development workflow.
When you create a merge request, the rule checks the name of the branch. If the branch name matches the rule, the merge request pre-selects the branch you specified in the rule as the target. If the branch name does not match, the merge request targets the default branch of the project.
Long-running issues with many threads can be challenging to read and track. You can now resolve a thread on an issue when the topic of discussion has concluded.
In 16.4, we released Fast-forward merge trains, and as a continuation, we want to ensure we support all merge methods. Now, if you want to ensure your semi-linear commit history is maintained you can use semi-linear fast-forward merge trains.
