Hello,

we've encountered an issue related to out-of-order execution of pre-receive hooks registered by different add-ons.

Example:

(in this example hooks are executed on push to Git repository)

App A - registeres "repository-hook" named "A-hook"
App B - registeres "repository-hook" named "B-hook"

Bitbucket Server executes hooks in alphabetical order of hook keys, there is no way to configure execution order explicitly.

So, user expected the following execution order:

A-hook, B-hook

In case A-hook rejects commit, B-hook should not be executed. However, there is a way to break this order that may lead to unexpected results (see below for particular example):

A-hook implements PreRepositoryHook:

preUpdate(context, ...)

{ context.registerCommitCallback(this); return ACCEPTED; }

getResult()

{ return REJECTED; }

B-hook implements PreRepositoryHook:

preUpdate(...)

{ return ACCEPTED; }

In the above example A-hook fails (so that commits are rejected and further hooks are not expected to be executed), but B-hook is still executed. That happens because commit callbacks results are only fetched after all hooks had been executed, not after each hook preUpdate call.

Particular example when this behaviour causes issues is:

• "SVN Mirror for Bitbucket Server App" hook that expects to be executed last only in case commits had not been rejected by other hooks and
• "YACC (yet another commit checker) App" that rejects commits only in by returning REJECTED result in commit callback "getResult" method, not in preUpdate method of the hook instance.

Above results in commits being finally rejected by Bitbucket Server, but committed to the mirrored SVN repository and eventually fetched back to Git repository, thus bypassing YACC policy check.

Suggestions:

1) Run registered commit callback and get its results before proceeding to the next hook execution.
2) Let user specify hook execution order explicitly in addition to default lexicographical order of execution.