I guess running scripts in a sandboxed environment using Docker is just too hard. Oh wait, that's what Bitbucket pipelines do! The only difference is before receiving instead of after receiving. 🙂🔫

Hi All, With pre-receive hooks, one can validate the commit author email. But now, with Bitbucket Cloud enabled with Forge capabilities, you can develop apps to place this check for a pull request merge.

For example, if a user's official email domain is "test.com" registered with Bitbucket Cloud, but they have set a different email domain "abc.com" using git config, they will still authenticate to Bitbucket Cloud using "test.com" and push commits. However, the commit author isn't recognized in the Bitbucket Cloud UI since "user@abc.com" doesn't exist as a valid Bitbucket Cloud user. Such merges to production branches can be blocked.

Here is a sample Forge app that performs this validation: Forge App Commit Email Author Validator. For example, it blocks any email domain other than "test.com".

+1 Yes, please. That would be great. I was looking for something like GitHub's secret scanner, that would refuse the push if it finds disallowed patterns in code.

@Swen Auerswald - We provide pre-defined additional checks via Flowie, including the recently released commit checks plugin, where you can validate among other things, the commit commit message against a regex. It can also be defined by branch/repo. It is not a server side 'pre-receive' hook, but as per already mentioned in this ticket this is unlikely to happen.  

I don't know if its currently possible, but given their messaging around Forge it seems like they're trying to make it possible for us to make these sorts of customizations. I think they're reluctant to implement it themselves because then they would have to jump through flaming design hoops to make it palatable to all of their customers.

Ok. If this will possible to do with Forge at all, I apparently would need to install Docker, Node.js, Forge and so on just to do the same thing a little script with a few lines could do ... There is a good German saying for that: Shooting sparrows with cannons ... Anyways, I will try to take a look into that ...

I suspect that the avenue for that kind of extension is Atlassian's Forge platform.

Our use case would be just to check the commit message on each push to a specific branch and reject the push if the check fails. The check would include: commit message starts with Jira issue key with specific prefix and following subject string is less than a specific number of chars. I understand that allowing users to upload their own scripts to the cloud would be a bad idea, but what about providing such a functionality via a repository setting where one could just enter a regex for commit messages and the branch name where this should apply for.

+1

Thank you Edmund, this looks very promising. Can you elaborate on the use cases where this will not work?

In addition, when will this functionality no longer be in beta?

Hi everyone - I wanted to share something with this group. But before I do, I want to preemptively acknowledge that this is NOT what this ticket is asking for, however it is something that I'm confident numerous people who are active on this ticket would be interested in.

First, I want to address the elephant in the room - why no server side "pre-receive" hooks in Bitbucket Cloud, despite the huge demand?

The answer is pretty simple:

Real, Git pre-receive hooks in a multi-tenanted, Cloud, SaaS environment is technically impossible.

This is due to the fact that Git pre-receive hooks invoke code that is deployed onto the machine that runs the remote Git server, which in this case would be Bitbucket Cloud. For obvious reasons, we can't have people pushing bash scripts to the servers running Bitbucket Cloud, that we then execute every time a commit comes in.

I'm not a security expert... but that just sounds like a remote code execution attack with extra steps.

However, that does not mean we aren't working to try to bring you capability to address the reasons this need exists.

You may be aware that in September last year, Bitbucket Cloud went live with its Open Beta for our implementation of Forge, Atlassian's product extensibility framework. The teams I work with are building out a framework that is designed to allow you to leverage Forge to achieve levels of extensibility for Bitbucket Cloud, the likes of which you would historically only associate with a traditional on-prem tools (https://bitbucket.org/blog/announcing-the-eap-of-forge-in-bitbucket-cloud).

The first pillar of this, which I believe will be of interest to people following this ticket, was our beta release of Custom Merge Checks, powered by Forge. This went into open beta in late December, more information is available here: https://bitbucket.org/blog/beta-custom-merge-checks-in-bitbucket-cloud

To be clear, not all use-cases for pre-receive hooks can be achieved with Custom Merge Checks, however a LOT can. From the research we did into customer use-cases, around 70% of use-cases for pre-receive hooks can be addressed (sometimes imperfectly), via Custom Merge Checks.

We are continuing to look into how we can bring similar capabilities to the "pre-receive" step of the process. However, technical limitations like those mentioned above mean that anything we do provide in this space will have constraints applied to it that reduce its ability to solve real-world problems. This is why we chose to deliver Custom Merge Checks first, as it has a much broader range of use-cases it can be used for with the implementation that is possible in a SaaS context.

If you would like to learn how to build a Forge app for Bitbucket Cloud (the first step in building Custom Merge Checks), take a look at our tutorial here: https://developer.atlassian.com/platform/forge/build-a-hello-world-app-in-bitbucket/

Once done, you can move on to adding Custom Merge Check functionality to your Bitbucket Cloud Forge app, following the guide here: https://developer.atlassian.com/platform/forge/manifest-reference/modules/bitbucket-merge-check/

If you have questions, feedback, or would like to get in touch, please feel free to contact me directly: emunday@atlassian.com

+1 need this.

+1 

+1

@Levente, GitHub is the first one. 

@Newthon Junior and others: if you contemplate other platforms that you would move to, what are those?

Sad but true. Atlassian ask you to vote to implement a feature. This has 1.100 VOTES!!!!!!!!!!!!!!! Almost 10 years to implement a feature. Is Atlassian waiting for 1 million?

Advising my company to leave Bitbucket too

+1

+1

+1 here

+1

Please, this must be an absolute priority

We are considering saying goodbye to Bitbucket as well. This issue is one motivator, though nowadays the biggest reason is that our bank keeps flagging their charges from the British Virgin Islands as potentially fraudulent and placing holds on our credit card because of it. I guess that's the kind of reputation Atlassian has these days!

Removing my vote due to abandoning Bitbucket for our team due to prolonged lack of feature parity with other services, including this issue and others. Cheers 🍻

<sigh>  yet another place where I find a 10+ year enhancement request that will never get completed </sigh>

Hi, This should be a priority. When can we expect this to be rolled out

Hi team, we have a requirement for custom branch templets and commit patterns, may i know when this server side hooks will be rolled out, these options are already available in gitlab.

Would be cool if Bitbucket could add a feature every other tool that isn't completely trash already has! It's annoying.

If you manage that, I think that's worth a holiday. You will be forever celebrated in the annals of history

I'm seriously considering to apply my CV to Atlassian to get this done

@eugene taranov
you have my sword. we'll need the address within a year or so

Well, we could all send CEO an anniversary cake with BCLOUD-10471 on top. He would be happy to receive three hundred cakes!

Damnit, we should have created a feature request for the birthday party 11 years ago then ...

Maybe instead of planning the 10yr party we should try to make a plan for each and every party that could be desired and work on them separately... like they're doing with this ticket. Instead of them using a webhook to hit a endpoint in our control where we can script/plan for anything we want, they want every use-case we desire so they can make individual add-ons for each goal. Our party planning could follow a similar path. I for one want hookers and blow at the 10 year anniversary.

Let's have a plan for the celebration of this feature request being created! 10 years anniversary! Give me some good options to celebrate!

+1

+1

970 votes for this issue don't seem to be enough, it's still "under consideration"

In 2 years we all could celebrate 10 years talking about it !!!! This is epic !!!! 

+1

+1

+1

+1

+1

Every environment I've worked in that uses Git has made use of git hooks to help maintain standards across the code base and development pipeline. The company I'm at now is the first one I've worked at that used Bitbucket Cloud. I'm shocked that after nine years this basic and widely depended on feature is still not supported. 

Disappointing to see that critical functionality we've relied on for years is missing from the cloud version that we're being forced to move to.

This is mandatory for several reasons, indeed auto-generating release notes but also because it allows you to add some rigor to the messages. In my team I have to supervise quite some juniors and they don't always have a strict message format.

Or could somebody provide steps to work-around this? In Bitbucket server there are a lot of options but it's being deprecated in favor of the cloud... but the cloud is missing features...

Also it's in the top three... I think it at least deserves some attention from Atlassian to provide insight why or why not? or better..when

We moved away from Bitbucket, and this was the only reason. We are happily verifying our commits on GitHub now. Sad that basic security is not part of Atlassian/Bitbucket's focus for a feature that has been requested for more than 8 years.

+1 .. A software development flow based on Pull Requests and auto-generating release notes is impossible without the possibility to enforce commit message formatting server-side.

This absolutely needs to be available.

+1 A much needed feature. Please provide support at the earliest.

2023 and this feature still not available?

+1 please bring to cloud...