Proposal: hook improvements

[guillep2k]

Here's a list of improvements for git and web hooks that might be of interest:

• [ ] Global hook templates It would be useful to maintain a global hook list under admin's control that repo owners can choose from, update, etc. Git hooks could be either stored in the file-system or added to the database as text.
  • [ ] Some details may be locked or open for the end user (e.g. destination URL, a query parameter in the case of web hooks, or some configuration variable to pass the git hook).
• [ ] Script webhooks There should be a type of web hook that triggers a local script instead of starting a POST.
• [ ] Vetted hooks It would be nice to enable custom hooks in repo templates as a way for admins/users with permission to create "vetted" git hooks and allow users to use them.
• [ ] Enforced hooks Another possibility is copying hooks even if the user has no permissions for them (i.e. forced by the admin/template ower---- with a warning, of course). That way admins can enforce policies, for example.
  • [ ] If an org owner has the proper permissions, they could enforce certain hooks for every repo that is created/transferred to the organization.
• [ ] Configure hooks location (e.g. core.hooksPath) to solve issues like noexec file-systems.

Related: #1089

[guillep2k]

A palette of git hooks with useful functionality could be added too. For example.

[zeripath]

Consider setting git config core.hooksPath:

By default Git will look for your hooks in the $GIT_DIR/hooks directory. Set this to different path, e.g. /etc/git/hooks, and Git will try to find your hooks in that directory, e.g. /etc/git/hooks/pre-receive instead of in $GIT_DIR/hooks/pre-receive.

The path can be either absolute or relative. A relative path is taken as relative to the directory where the hooks are run (see the "DESCRIPTION" section of githooks[5]).

This configuration variable is useful in cases where you’d like to centrally configure your Git hooks instead of configuring them on a per-repository basis, or as a more flexible and centralized alternative to having an init.templateDir where you’ve changed default hooks.

[zeripath]

We could actually set this and avoid the no exec problem in gitea-repositories etc.

[guillep2k]

Consider setting git config core.hooksPath:

@zeripath Can this be generalized as "add configurable settings to .git/config on repo creation"? So other settings can be added (I don't know, there might be something else that's useful). For example, in app.ini:

[git]
CONFIG_TEMPLATE = git.config

Then, in git.config:

[core]
hooksPath = {GITEA_DIR}/hooks/{OWNER}/{REPO}

I guess we need to keep Gitea from managing them (e.g. overwrite them?), however.

[zeripath]

Yeah that could very easily be done. Writing to the per repository git config is probably the best bet as then any git commands that try to touch the repo outside of Gitea automatically also get the settings.

I think it's find if Gitea touches other git config settings - they're our repos in the end.

We also need to manage how configs work with our temporary repos.

[alexanderadam]

• Script webhooks There should be a type of web hook that triggers a local script instead of starting a POST.

this point is basically related to issue 1089, isn't it?

[guillep2k]

@alexanderadam I'll link that issue here, since this one is more comprehensive.

[antipatico]

I am sorry to revamping a nearly 2 years old topic, but I am having this issue when running gitea with docker.

I mounted the disk containing /var/lib/docker/volumes with the noexec flag, resulting in all the volumes in my docker images being noexec, including /data for gitea. This results in hook scripts which never run in my system.

Is there a workaround? As I understood the proposed API has not been implemented yet and I am not well versed enough with the project to contribute by myself.

Thanks!

[Danoloan10]

How about adding the --template argument here? https://github.com/go-gitea/gitea/blob/68704532c28cf09db96c988291b2f82c5e615984/modules/git/repo.go#L75 According to git-init(1):

TEMPLATE DIRECTORY
       Files and directories in the template directory whose name do not start
       with a dot will be copied to the $GIT_DIR after it is created.

       The template directory will be one of the following (in order):

       •   the argument given with the --template option;
       •   the contents of the $GIT_TEMPLATE_DIR environment variable;
       •   the init.templateDir configuration variable; or
       •   the default template directory: /usr/share/git-core/templates.

       The default template directory includes some directory structure,
       suggested "exclude patterns" (see gitignore(5)), and sample hook files.

       The sample hooks are all disabled by default. To enable one of the
       sample hooks rename it by removing its .sample suffix.

So another option would be to set the GIT_TEMPLATE_DIR environment variable in an specific setup.

I've tried setting the init.tempalteDir option in the .gitconfig file of the user running the Gitea server but it didn't work. Gitea might be doing something to the execution context of the commands or the git config that I'm not aware of.

But that would not be enough, the hook resync admin action should reinstall the template too. Maybe that's a new "reinit" action?