Proposal: hook improvements #4291

New Issue

GiteaMirror · 2025-11-02T05:44:59-06:00

GiteaMirror commented

2025-11-02 05:44:59 -06:00

Originally created by @guillep2k on GitHub (Nov 12, 2019).

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

Originally created by @guillep2k on GitHub (Nov 12, 2019). 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

GiteaMirror added the type/proposal type/summary labels 2025-11-02 05:44:59 -06:00

GiteaMirror commented

2025-11-02 05:45:00 -06:00

@guillep2k commented on GitHub (Nov 12, 2019):

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

@guillep2k commented on GitHub (Nov 12, 2019): A palette of git hooks with useful functionality could be added too. [For example](https://github.com/go-gitea/gitea/issues/2770#issuecomment-553114472).

GiteaMirror commented

2025-11-02 05:45:00 -06:00

@zeripath commented on GitHub (Nov 12, 2019):

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 commented on GitHub (Nov 12, 2019): 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.

GiteaMirror commented

2025-11-02 05:45:01 -06:00

@zeripath commented on GitHub (Nov 12, 2019):

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

@zeripath commented on GitHub (Nov 12, 2019): We could actually set this and avoid the no exec problem in gitea-repositories etc.

GiteaMirror commented

2025-11-02 05:45:01 -06:00

@guillep2k commented on GitHub (Nov 23, 2019):

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.

@guillep2k commented on GitHub (Nov 23, 2019): > > > 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.

GiteaMirror commented

2025-11-02 05:45:01 -06:00

@zeripath commented on GitHub (Nov 23, 2019):

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.

@zeripath commented on GitHub (Nov 23, 2019): 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.

GiteaMirror commented

2025-11-02 05:45:01 -06:00

@alexanderadam commented on GitHub (Nov 25, 2019):

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?

@alexanderadam commented on GitHub (Nov 25, 2019): > * **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](https://github.com/go-gitea/gitea/issues/1089), isn't it?

GiteaMirror commented

2025-11-02 05:45:02 -06:00

@guillep2k commented on GitHub (Nov 25, 2019):

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

@guillep2k commented on GitHub (Nov 25, 2019): @alexanderadam I'll link that issue here, since this one is more comprehensive.

GiteaMirror commented

2025-11-02 05:45:02 -06:00

@antipatico commented on GitHub (Sep 27, 2022):

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!

@antipatico commented on GitHub (Sep 27, 2022): 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!

GiteaMirror commented

2025-11-02 05:45:02 -06:00

@Danoloan10 commented on GitHub (Jan 31, 2023):

How about adding the --template argument here?
68704532c2/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?

@Danoloan10 commented on GitHub (Jan 31, 2023): 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?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4291