Handle global custom hooks for gitlab-shell

Mentioned in merge request gitlab-shell!111 (merged)

Thanks for creating this issue @smcgivern.

Maybe to bring more context to this for people unfamiliar with the gitlab MR:

<project>.git/hooks is a symlink to gitlab-shell/hooks
gitlab-shell/hooks/{pre-receive,update,post-receive} are not meant to be customizable
in order to have globally customizable hooks, gitlab-shell/hooks/{pre-receive,update,post-receive}.d/ directories were introduced

Now the question is how to bring this to omnibus installations, where gitlab-shell/hooks resides in the non-customizable /opt/gitlab/embedded/service path. As @smcgivern proposed, symlinking is an option, either configurable via /etc/gitlab.rb or by simply using a location in /var/opt/gitlab (e.g. /var/opt/gitlab/hooks/{pre-receive,update,post-receive}.d/). Or an even better third option :-)

Thanks all for thinking about this before merge. Here are a few things we want to consider:

We cannot have user provided configuration in gitlab-shell/hooks directory. Every package upgrade is going to delete the files introduced there.
Placing any user stored configuration in /var/opt/gitlab/ is also not possible because for any directory/file we don't expect any manual user intervention. All files in there are handled by the package to a certain extent.

The user is already used to having all configuration done in /etc/gitlab directory, be it through gitlab.rb configuration file, SSL certificates or something else. We also instruct users to backup the whole /etc/gitlab directory.

So this is also my proposal, use this directory to store custom_hooks and have reconfigure link to the location gitlab-shell can reuse.

With this we keep in line with user expectations, our recommendations and also with the fact that any upgrade should not change the files in /etc/gitlab.

@ibaum What do you think about this?

@marin, yes, you are right of course. I have had /etc/gitlab/hooks/{pre-receive.d,update,post-receive}.d/ or similar in mind, not sure why I typed out /var/opt/gitlab.

@marin I agree that /etc/gitlab is the best default location for this.

We might further consider mirroring the SSL certificate behavior, and have that be an attribute with a default value. Allow users to store their hooks elsewhere if they need to.

@ibaum thanks! What do we need to do next?

assigned to @ibaum

I am having second thoughts about this, will do a chat with @smcgivern to see if we can find alternative approach.

@marin and I talked, and we're going to do this:

Add a config option to set the global hooks parent dir in gitlab-shell.
If that's not set, it defaults to gitlab-shell/hook.
If it is set, we use that, and it's the user's responsibility to ensure permissions etc. are correct.
Omnibus will just enable setting this in gitlab-shell's config.yml, but won't be responsible for everything else.

created branch 1754-handle-global-custom-hooks-for-gitlab-shell

mentioned in merge request !1155 (merged)

@ibaum I'm sorry, I've just noticed the above was imprecise. What I should have said was that this configuration option only applies to the global custom hooks, not to the default hooks which we provide in gitlab-shell/hooks. So in the default configuration:

We will read our global hooks from gitlab-shell/hooks/{pre-receive,update,post-receive}.
We will read custom global hooks from gitlab-shell/hooks/{pre-receive,update,post-receive}.d/*.

If the configuration option (which I'm calling custom_hook_dir) is set to /foo/bar:

We will read our global hooks from gitlab-shell/hooks/{pre-receive,update,post-receive}.
We will read custom global hooks from /foo/bar/{pre-receive,update,post-receive}.d/*.

mentioned in merge request gitlab-shell!113 (merged)

One addition to the above: there should never be global custom hooks installed in the default configuration with Omnibus. I will try to clarify this in the docs.

@smcgivern I've updated !1155 (merged), please let me know if that's in line with what you're looking for.

mentioned in commit gitlab-shell@92dad7c1

closed via merge request !1155 (merged)

mentioned in commit tnir/omnibus-gitlab@49f966b1

mentioned in commit ee3a8366

mentioned in commit 792be70b

@ibaum @smcgivern My gitlab version is 9.3.6. I asked the same doubt in GitLab forum aslo. But I did not get any solution for this. So Only I asked here. Kindly help me.

I have created the global custom hook in the location of /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/pre-receive. I just tested if the hook is firing or not during git push. But I did not get the output in git push output screen. My doubt is, Is my hook configuration is right or wrong? Why does It not firing?

@arunkumar.nagarajan I just tested this on 9.2.2, and it works fine for me:

Counting objects: 3, done.
Writing objects: 100% (3/3), 241 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: hi
To http://localhost:5679/root/custom-hooks-test.git
   dc39b0d..c7d06c0  master -> master

Is your file /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/pre-receive executable?

@smcgivern Thank you very much for your responce :-)

Is your file /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/pre-receive executable?

How can I check / do this?

@arunkumar.nagarajan that's really beyond the realm of what we can explain in the context of GitLab, but https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions might be useful for you.

In this case, you should be able to do chmod +x /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/pre-receive.

@smcgivern Thank you very much for your guiding, Now it is working. Thank you very much

Handle global custom hooks for gitlab-shell

Designs

Child items 0

Activity

Admin message

Admin message

Handle global custom hooks for gitlab-shell

Activity