Custom merge checks are now generally available

[#1]

Round 2 of the announcements for today!

We're excited to announce that Custom merge checks are now officially generally available. If you haven't started using custom merge checks yet, now is the time to jump in and get started!

Check out our official announcement blog for all the details.

[Arend Lapere]

This is truly awesome and I've implemented my first forge app in literal minutes so kudos to the entire team and for listening to the requests regarding this! Sometime earlier this month, it was mentioned that this is either configurable on repo level as well a project level but I don't see it under my project settings? Is this because of authorization or is this to be added in an upcoming release? BTW I'm using bitbucket pre-commit checks for now as this was my primary use case

[Edmund Munday]

Hi @Arend Lapere - Thanks for the awesome feedback, so glad you found it easy to setup and start using, that's been a huge focus for us.

Today, Project / Workspace Checks are not available sorry! That's next on the list though, so stay tuned.

I'd love to learn a bit more about your use-cases for Project level vs Workspace level. What kind of things are you trying to solve with these?

[Arend Lapere]

Currently I've two major use-cases:

• enforcing a specific commit message format (so I can have a structured, automated changelog)
• checking that the PR is not desynced from the target branch (already implemented this). I enforce that every PR to main has a version that hasn't been "released" yet (a release is tracked by tagging the code and if that tag already exists, I fail to release the build artifact). If multiple PRs have the same unreleased version, they will build just fine but after the rebase to main it goes wrong because of this

Future use-case for me:

• Check if there is version updated included somewhere in the PR

The other things are already managed just fine by the built-in merge checks (that work on the project level though)

Why do I want project level support you ask? Because we have a lot of tiny repositories (e.g. micro-services, micro-frontends, tools, middleware, libraries, ...), and they are grouped under a project (usually under the product line that they belong to). Managing via project allows me to quickly set these things up, instead of having to do it manually each time a new merge check would be available. More so, if I'd forget any of these repositories, than my rules are not enforced and that MIGHT cause an issue in the long run.

So, I'll stay tuned for when this lands on the project level, we're still in the  process of migrating from BitBucket server to Cloud so at this point in time I am focused on ticking the right checkboxes for each repo and it will probably be all fine for now.