Note: Custom Git hooks must be configured on the filesystem of the GitSwarm server. Only GitSwarm server administrators will be able to complete these tasks. Please explore webhooks as an option if you do not have filesystem access. For a user configurable Git hook interface, please see GitSwarm Enterprise Edition Git Hooks.
Git natively supports hooks that are executed on different actions. Examples of server-side git hooks include pre-receive, post-receive, and update. See Git SCM Server-Side Hooks for more information about each hook type.
As of gitlab-shell version 2.2.0 (which requires GitSwarm 2015.2+), GitSwarm administrators can add custom git hooks to any GitLab project.
Normally, Git hooks are placed in the repository or project's hooks
directory. GitSwarm creates a symlink from each project's hooks
directory to the gitlab-shell hooks
directory for ease of maintenance between gitlab-shell upgrades. As such, custom hooks are implemented a little differently. Behavior is exactly the same once the hook is created, though.
Follow the steps below to set up a custom hook:
/home/git/repositories/<group>/<project>.git
. For package installations the path is usually /var/opt/gitswarm/git-data/repositories/<group>/<project>.git
.custom_hooks
.custom_hooks
directory, create a file with a name matching the hook type. For a pre-receive hook the file name should be pre-receive
with no extension.#!/usr/bin/env ruby
.That's it! Assuming the hook code is properly implemented the hook will fire as appropriate.
Introduced in GitSwarm 2016.3.
If the commit is declined or an error occurs during the Git hook check, the STDERR or STDOUT message of the hook will be present in GitSwarm's UI. STDERR takes precedence over STDOUT.