-
Suggestion
-
Resolution: Unresolved
There are multiple cases when development teams want to check the push to the remote repository and either accept or reject it. Some may check branch names, commit messages, fast-forward merges, etc. to ensure the development process follows some particular rules.
Currently, it does not seem to be possible with Bitbucket to use this functionality that actually comes out of the box with Git. The user does not have access to the actual remote repository to manage that. However, it can be provided in a different way using the approach similar to Bitbucket Hooks' POST request. When the repository gets triggered on "pre-receive" event, it could execute HTTP POST request supplying all the information from the push, and accept it if the POST request returns 200 or reject if any other HTTP code. This would still not require to provide direct access to the remote repository, but the users could still handle commits and reject them using their specific rules.
PS Related but less generalized ticket:
Enhancement BCLOUD-5658 Allow custom pre-receive hook that rejects commits without an issue key in their message
- relates to
-
- Gathering Interest
- is related to
-
ENT-1421 Failed to load
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
[BCLOUD-10471] Git server-side "pre-receive" hook (BB-11418)
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
All comments
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.
+1000 amazing this isn't implemented and they expect us to use F`ing forge for something so simple.
@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.
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. 🙂🔫