Skip to content

Conversation

netdata-be
Copy link

I know the prefered way is using web hooks.
But we also have some bash scripts which we realy need. For example we
want things like rsync to trigger, doing this using webhooks would
require me to write an HTTP app for this.

The same is true for post-receive hooks, we would like to force server
side syntax checking and style checks.

I understand that this is not maintained by gitlab therefore call all
scripts located in the update.d

I know the prefered way is using web hooks.
But we also have some bash scripts which we realy need. For example we
want things like rsync to trigger, doing this using webhooks would
require me to write an HTTP app for this.

The same is true for post-receive hooks, we would like to force server
side syntax checking and style checks.

I understand that this is not maintained by gitlab therefore call all
scripts located in the update.d
@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling f04042e on netdata:Allow_custom_hooks into eee3f27 on gitlabhq:master.

@netdata-be
Copy link
Author

@coveralls
Copy link

Coverage Status

Coverage decreased (-0%) when pulling 45aa0fc on netdata:Allow_custom_hooks into eee3f27 on gitlabhq:master.

@leoneparise
Copy link

The update hook should reject the package if any script in update.d dir fail. How do you do this?

@netdata-be
Copy link
Author

@castovoid you are right, I will make a change

@jacobvosmaer
Copy link
Contributor

Thank you for your pull request. We have thought about this and we think it would be better if users that need custom update or post-receive hooks simply edit the files that GitLab puts there. We have changed the comments to reflect this recommendation.

@netdata-be
Copy link
Author

@jacobvosmaer Thanks.

Actually I still think this could be very useful since it will not break gitlabs-shell when updating while providing users a standard way of chaining custom hooks.

If you think this is really not needed I would like to document it what would be the preferred way?

@leoneparise
Copy link

I agree with @netdata. Putting our hook logic inside the update script will break gitlab-shell when updating. update.d folder should be the best option.

@netdata-be
Copy link
Author

@jacobvosmaer I have also rebased this MR would you needed it

@netdata-be
Copy link
Author

@jacobvosmaer Is this a definitive decision?
This request seems to very popular for a long time, in the past I made the same merge request and was also closed.
See also this old thread https://github.com/gitlabhq/gitlabhq/issues/476

Just want to hammer once more since I don't see anything wrong with supporting this officially, everyone who wants to customize this hook has the same issue:

  • Uncertain for future releases, they might brake stuff
  • Everyone has to figure out how to chain hooks

If it helps I willing to make the required documentation inside the gitlab project.

Just waiting on your final answer

Thanks

@jacobvosmaer
Copy link
Contributor

@netdata thank you for pointing to some more of the history of this idea. We are still discussing this; I will let you know about the outcome.

@cburyta
Copy link

cburyta commented Aug 23, 2013

+1 to a way to support this, our use case would be to be able to "git push --mirror REMOTE" , and web hooks just don't cut it.

@nachinius
Copy link

+1 this is important. Why would I lost the power of have the repo in my own machine, if I can't put per repo hooks ?

@jacobvosmaer jacobvosmaer mentioned this pull request Aug 26, 2013
4 tasks
@jacobvosmaer
Copy link
Contributor

Also see #85; +1's welcome.

@jait
Copy link

jait commented Dec 27, 2013

👍 +1

@alerque
Copy link

alerque commented Jan 25, 2014

Support for custom scripts as hooks is THE main feature I am evaluating before selecting a new git hosting solution. Forcing folks to write an HTTP API just to handle these is silly. That this feature request has not been handled and repeated pull requests have been either closed or are still sitting open is the main concern I have considering a switch to Gitlab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

8 participants