-
Bug
-
Resolution: Fixed
-
Medium
-
None
-
2
-
Severity 2 - Major
-
4
-
Symptoms
- Pull requests are not being updated when the source or target branch is updated
- Configured repository hooks are not being enforced when updates are pushed to a repository
- Branch permissions are not being enforced when updates are pushed to a repository
The atlassian-bitbucket.log contains this message:
2018-02-08 10:17:33,857 WARN [http-nio-7990-exec-9] admin @X98WX6x617x66x0 127.0.0.1 "POST /scm/test/test.git/git-receive-pack HTTP/1.1" c.a.s.i.s.g.p.http.HttpReceivePack TEST/test[1]: Git hooks have not been called. Please verify that the hooks are configured correctly - see https://confluence.atlassian.com/display/BITBUCKETSERVERKB/Git+hook+scripts+are+not+executing?utm_campaign=in-app-help&utm_medium=in-app-help&utm_source=stash for details
Summary
The symptoms described above indicate that the repository hooks in Bitbucket's repositories are not being called. This can have a variety of reasons (e.g. hooks being manually overwritten, hooks not being executable). More information about possible causes and ways to resolve them can be found in this Knowledge Base article.
This problem also occurs when the core.hooksPath setting (supported in git 2.9 and higher) is configured in the ~/.gitconfig file of the Bitbucket (service) user, or in the system-wide /etc/gitconfig configuration file, Bitbucket Server's repository hooks are no longer called.
Bitbucket should override the core.hooksPath setting in its shared/config/git/system-config to ensure its own hooks are called.
Workaround
Remove the core.hooksPath setting from the Bitbucket user's ~/.gitconfig and/or the system-wide /etc/gitconfig.
[BSERV-10609] Hooks are not being called when core.hookspath is configured in system or user level git config file
What Bitbucket Server does on the server side of a hosting operation is irrelevant to and has no effect on what clients do. If remote clients have set core.hooksPath, it'll do what it does. Client-side hooks can't interfere with server-side processing.
I'm not sure what you're trying to accomplish with hooks, from your question. pre-commit, prepare-commit-msg and pre-push hooks will never be invoked on a Bitbucket Server instance regardless of how they're set, because Bitbucket Server doesn't run git commit (from within the repositories, anyway; there's a little nuance to this) or git push. The only hooks the server-side cares about (or runs) are pre-receive and post-receive (though Git itself will also run update for some things).
If you're looking for a server-side hook, our Java APIs for it are better than Git's script-level integration point simply because there's a lot of Bitbucket Server functionality (merging pull requests, in-browser file editing, many more) that doesn't trigger any hooks at the Git level. They're only triggered in software.
If you're trying to share hooks between developers, for use on their local machines, feel free to manage it however you want. Git itself offers no support for having the server provide hooks to clients (it's a security nightmare and they've chosen to simply not offer it), so nothing Bitbucket Server does can really "help" with that--and, by the same token, it can't interfere with it either.
Hope this helps,
Bryan Turner
@Byran Turner, so it sounds like you're saying although on Bitbucket Server 7.2+ I can use core.hookspath to define path to git hooks scripts, I shouldn't, because there are several contexts in which they won't get run, and instead should opt for a server-side plugin that implements either `PreRepositoryHook`/`PostRepositoryHook` or `HookScriptService`.
Is this really relevant for someone looking to implement local git hooks that run on the client only, e.g. pre-commit, prepare-commit-msg and pre-push hooks? It would seem that this should be "safe" to do with core.hookspath, with the understanding that these will never be triggered by server-side actions.
Next week we're getting on Bitbucket Data Center 7.6 LTS and I'd like to know best practice for sharing hooks with the teams that I support.
Bitbucket Server 7.2.0 overrides core.hooksPath regardless of the level it's set at when receiving pushes. (Bitbucket Server passes -c core.hooksPath=hooks on the git http-backend and git receive-pack command lines now, which will take precedence over any configuration file, including repository-specific ones.) Anyone who is relying on the ability to customize hooks by using core.hooksPath, which has always been an unsupported behavior, will no longer be able to do so.
To write and apply reusable hooks, they should either be written using Bitbucket Server's Java PreRepositoryHook or PostRepositoryHook SPIs, or, for script-style hooks, they should be created and managed using Bitbucket Server's HookScriptService (which requires writing a Java plugin, currently; the system does not provide any REST API or UI screens for creating/managing hook scripts). Applying hook scripts directly to repositories, whether via pre-receive/post-receive or by setting core.hooksPath, leaves a significant number of gaps. For example, branch creation and deletion, tag creation and deletion, pull request merges and in-browser editing all do not invoke Git's pre-receive or post-receive hooks. The Java hook SPIs and scripts managed using HookScriptService, on the other hand, do get invoked for all those operations--and more besides.
As a heads up, future architectural changes to Bitbucket Server, which are actively in development, will only make it harder to try and manually set up scripts on disk. Our changes aren't deliberately trying to do so, but in order to ensure performance and stability the system requires the ability to know how its repositories work, and how they're interacted with. Repository modifications, like installing scripts, outside of Bitbucket Server introduce variables we simply can't predict or plan for.
Best regards,
Bryan Turner
Atlassian Bitbucket
core.hookspath is a primary convenience git provides for teams to easily automate sharing hooks. It is a huge problem to not be able to use this git feature because Bitbucket implementation can't ensure that its own hooks are called.
Thanks @Bryan Turner, that confirms my analysis which I now see should have been rather obvious (to me). Ultimately, we'll be doing both client-side hooks for developer utilities and guard rails, and server-side hooks for policy enforcement. When we do the latter, I'll take Atlassian's suggestions and implement them in Java.