11 KiB
stage | group | info | disqus_identifier |
---|---|---|---|
Systems | Gitaly | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments | https://docs.gitlab.com/ee/administration/custom_hooks.html |
Git server hooks (FREE SELF)
- Introduced in GitLab 12.8 replacing Custom Hooks.
- Renamed from server hooks to Git server hooks in GitLab 15.6.
Git server hooks (not to be confused with system hooks or file hooks) run custom logic on the GitLab server. You can use them to run Git-related tasks such as:
- Enforcing specific commit policies.
- Performing tasks based on the state of the repository.
Git server hooks use pre-receive
, post-receive
, and update
Git server-side hooks.
GitLab administrators configure server hooks on the file system of the GitLab server. If you don't have file system access, alternatives to server hooks include:
- Webhooks.
- GitLab CI/CD.
- Push rules, for a user-configurable Git hook interface.
Geo doesn't replicate server hooks to secondary nodes.
Create server hooks for a repository
To create server hooks for a repository:
- On the top bar, select Main menu > Admin.
- Go to Overview > Projects and select the project you want to add a server hook to.
- On the page that appears, locate the value of Gitaly relative path. This path is where server hooks must be located.
- If you are using hashed storage, see Translate hashed storage paths for information on interpreting the relative path.
- If you are not using hashed storage:
- For Omnibus GitLab installations, the path is usually
/var/opt/gitlab/git-data/repositories/<group>/<project>.git
. - For an installation from source, the path is usually
/home/git/repositories/<group>/<project>.git
.
- For Omnibus GitLab installations, the path is usually
- On the file system, create a new directory in the correct location called
custom_hooks
. - In the new
custom_hooks
directory:- To create a single server hook, create a file with a name that matches the hook type. For example, for a
pre-receive
server hook, the filename should bepre-receive
with no extension. - To create many server hooks, create a directory for the hooks that matches the hook type. For example, for a
pre-receive
server hook, the directory name should bepre-receive.d
. Put the files for the hook in that directory.
- To create a single server hook, create a file with a name that matches the hook type. For example, for a
- Make the server hook files executable and ensure that they are owned by the Git user.
- Write the code to make the server hook function as expected. Git server hooks can be in any programming language. Ensure
the shebang at the top reflects the language type. For
example, if the script is in Ruby the shebang is probably
#!/usr/bin/env ruby
. - Ensure the hook file does not match the backup file
pattern (
*~
).
If the server hook code is properly implemented, it should execute when the Git hook is next triggered.
Gitaly Cluster
If you use Gitaly Cluster, the scripts must be copied to every Gitaly node that has a replica of the repository. Every Gitaly node needs a copy because any node can be made a primary at any time. Server hooks only run on primary nodes.
The location to copy the scripts to depends on where repositories are stored:
- In GitLab 15.2 and earlier, Gitaly Cluster uses the hashed storage path reported by the GitLab application.
- In GitLab 15.3 and later, new repositories are created using
Praefect-generated replica paths,
which are not the hashed storage path. The replica path can be identified by
querying the Praefect repository metadata
using
-relative-path
to specify the expected GitLab hashed storage path.
Create global server hooks for all repositories
To create a Git hook that applies to all repositories, set a global server hook. Global server hooks also apply to:
- Project and group wiki repositories. Their storage directory names are in the format
<id>.wiki.git
. - Design management repositories under a project. Their storage directory
names are in the format
<id>.design.git
.
Choose a server hook directory
Before creating a global server hook, you must choose a directory for it.
For Omnibus GitLab installations, the directory is set in gitlab.rb
under gitaly['custom_hooks_dir']
. You can either:
- Use the default suggestion of the
/var/opt/gitlab/gitaly/custom_hooks
directory by uncommenting it. - Add your own setting.
For installations from source:
- The directory is set in a configuration file. The location of the configuration file depends on the GitLab version:
- For GitLab 13.1 and later, the directory is set in
gitaly/config.toml
under the[hooks]
section. However, GitLab honors thecustom_hooks_dir
value ingitlab-shell/config.yml
if the value ingitaly/config.toml
is blank or non-existent. - For GitLab 13.0 and earlier, the directory set in
gitlab-shell/config.yml
.
- For GitLab 13.1 and later, the directory is set in
- The default directory is
/home/git/gitlab-shell/hooks
.
Create the global server hook
To create a global server hook for all repositories:
- On the GitLab server, go to the configured global server hook directory.
- In the configured global server hook directory, create a directory for the hooks that matches the hook type. For example, for a
pre-receive
server hook, the directory name should bepre-receive.d
. - Inside this new directory, add your server hooks. Git server hooks can be in any programming language. Ensure the
shebang at the top reflects the language type. For example, if the
script is in Ruby the shebang is probably
#!/usr/bin/env ruby
. - Make the hook file executable, ensure that it's owned by the Git user, and ensure it does not match the backup file
pattern (
*~
).
If the server hook code is properly implemented, it should execute when the Git hook is next triggered. Hooks are executed in alphabetical order by filename in the hook type subdirectories.
Chained server hooks
GitLab can execute server hooks in a chain. GitLab searches for and executes server hooks in the following order:
- Built-in GitLab server hooks. These server hooks are not customizable by users.
<project>.git/custom_hooks/<hook_name>
: Per-project hooks. This location is kept for backwards compatibility.<project>.git/custom_hooks/<hook_name>.d/*
: Location for per-project hooks.<custom_hooks_dir>/<hook_name>.d/*
: Location for all executable global hook files except editor backup files.
Within a server hooks directory, hooks:
- Are executed in alphabetical order.
- Stop executing when a hook exits with a non-zero value.
Environment variables available to server hooks
You can pass any environment variable to server hooks, but you should only rely on supported environment variables.
The following GitLab environment variables are supported for all server hooks:
Environment variable | Description |
---|---|
GL_ID |
GitLab identifier of user that initiated the push. For example, user-2234 . |
GL_PROJECT_PATH |
(GitLab 13.2 and later) GitLab project path. |
GL_PROTOCOL |
(GitLab 13.2 and later) Protocol used for this change. One of: http (Git push using HTTP), ssh (Git push using SSH), or web (all other actions). |
GL_REPOSITORY |
project-<id> where id is the ID of the project. |
GL_USERNAME |
GitLab username of the user that initiated the push. |
The following Git environment variables are supported for pre-receive
and post-receive
server hooks:
Environment variable | Description |
---|---|
GIT_ALTERNATE_OBJECT_DIRECTORIES |
Alternate object directories in the quarantine environment. See Git receive-pack documentation. |
GIT_OBJECT_DIRECTORY |
GitLab project path in the quarantine environment. See Git receive-pack documentation. |
GIT_PUSH_OPTION_COUNT |
Number of push options. See Git pre-receive documentation. |
GIT_PUSH_OPTION_<i> |
Value of push options where i is from 0 to GIT_PUSH_OPTION_COUNT - 1 . See Git pre-receive documentation. |
Custom error messages
You can have custom error messages appear in the GitLab UI when a commit is declined or an error occurs during the Git hook. To display a custom error message, your script must:
- Send the custom error messages to either the script's
stdout
orstderr
. - Prefix each message with
GL-HOOK-ERR:
with no characters appearing before the prefix.
For example:
#!/bin/sh
echo "GL-HOOK-ERR: My custom error message.";
exit 1