Make instance-wide custom git hooks configurable in the administrator UI
Problem to solve
Follow-on from a throwaway in Slack: https://gitlab.slack.com/archives/C3ER3TQBT/p1550502270143900 and https://gitlab.com/gitlab-org/gitlab-ce/issues/48132
Custom hooks are a difficult-to-configure GitLab feature: https://docs.gitlab.com/ee/administration/custom_hooks.html - especially in a HA environment, they depend on systems administrators configuring them in exactly the same way on every Gitaly server. This makes using them difficult, and debugging them even harder.
There's also no scope for per-hook configuration, such as "this hook's output is safe to display", which is something I found myself wanting recently
Target audience
-
Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
-
Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
Further details
Ain't nobody got time for that
Proposal
Allow an instance administrator to upload an archive containing custom hooks to GitLab. This archive is distributed to every Gitaly server on a regular (say, hourly) basis. This could happen even across ~Geo instances, ensuring that primary and secondary have identical custom hook configuration (some hooks are relevant to fetch).
Thought: instead of an archive, this could be a project, in the same way instance templates work. LFS can be used to store compiled binaries efficiently, but most of the time, hooks are going to be small scripts in bash/ruby/perl/etc. Development can then use GitLab
In the future, we can build a small frontend around the archive/project that allows metadata about each hook - for instance, "do not display output from this one", "only show stdout", "only show output if it exits with code N", or "disable this one for now" - to be configured.
Documentation
https://docs.gitlab.com/ee/administration/custom_hooks.html
What does success look like, and how can we measure that?
Instance administrators can view and change their custom hooks on a complex multi-site deployment without