In addition to merge checks, also hooks are sometimes(?) called to verify pull requests: bug or feature?

pre-recieve-hook
hook
mergecheck

#1

We have seen this really odd behavior that I cannot explain.

When looking at a pull request via the web interface, its “mergeability” is calculated by calling the merge check(s) activated in the target repository. That’s fine.
But, in some situations, also the hook(s) in the target repository are called?!

This can be reproduced with Bitbucket 5.2, using built-in hooks and merge checks. (I can share a test case if necessary.)

I couldn’t decide if this is a bug or a feature.

We thought it may be a feature and the idea is that the pre-receive hook wants to verify if the commits in the pull request are allowed to be added to the target repo and branch.
But there are two symptoms that contradict this:

  1. Seemingly, the hook is called before the merge check (so timing is counter-intuitive)
  2. The hook receives a empty collection of ref changes (so the hook cannot really do anything meaningful)

So, how is this supposed to work? Is this a bug or a feature?


#2

Anyone from Atlassian or the Bitbucket team can comment on this?

(If this is a bug, it can painfully break people’s workflows…)


#3

Hi @aron.gombas,

I saw a similar question raised in the Developer support service desk (DEVHELP-1182). We’ve replied to your question there and hope that answers the question.

Cheers,
Ian


#4

@iragudo Yep, thanks for the answer there. As I replied it took quite some efforts, but now we have a better understanding how hooks are invoked by Bitbucket.


#5

Hi if it makes sense if there isn’t sensitive information can you add the answer here in case others run into this problem in the future?

cc. @iragudo @aron.gombas


#6

This is intended and depends on how the hook was configured:

  1. you can write hooks that are only called for pushes, or
  2. you can also write hooks that are called for any ref change

The ‘mergeability’ check includes a so-called ‘dry-run’ invocation of the repository hook. Based on this scenario, at that time, the list of ref changes is empty but the pull request details (from / to branch) are available on the hook request.