git-hook CI Jobs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Git-hook CI Jobs aka yet another reason GitLab and GitLab-CI is awesome.

Description

  • Git admins need to be wary of user controlled server-side git hooks, especially public services such as gitlab.com and github.com. The security concern makes custom server side git hooks "impossible" and even with self hosted or detected git the admins become the gateway to ensuring safety and to deploy the hooks.
  • Push Rules are slick but only for the small number of predefined rules and for all branches.
  • GitLab (and all of its users) could have a massive win in enabling server side-hooks with project level control and is uniquely positioned to be able to do so by allowing server-side hooks to be executed in GitLab-CI jobs.

Benefits

Better Git Flow (I want to lint MR commit messages) and could solve a bunch of related issues such as:

Greatly exampled the concept of Push Rules

Super competitive compared to signing up for GitHub Enterprise just for a few server-side git hooks and something that other git providers will not be in as good of a position to answer as GitLab.

Further promote GitLab-CI and the power of the finely integrated solution.

Proposal

Integration with GitLab-CI such that:

The repository settings page has another option to enable GitLab-CI git hooks option. When enabled, GitLab will invoke a CI job on each event. If the job does not exist, then the hook exits 0 and moves on.

# conceptual hook script

#!/bin/sh

has_hook_stage () {
  [ -f .gitlab-ci.yml ] && cat .gitlab-ci.yml | grep -q "\"$1\"[[:space:]]*:"
}

has_hook_stage pre-receive || exit 0

pre-receive || {                                                                                            
  echo                                                                                                                
  echo "error messages"                                                
  exit 1                                                                                                              
}

pre-receive () {
  curl --request POST --form token=$TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
}

The feature would have predefined and reserved stage names that 1:1 match git hooks. GitLab-CI would assume these stages exists, without spelling em out, but it would be OK to require the user to declare the stage:

# conceptual reserved stage names

stages:
  - build
  - test
  - deploy

lint-mr-mesg:
  stage: git-pre-receive
  script:
    - conventional-changelog-lint -e
  only:
    - master

In the pipeline web view I would see a git-pre-receive stage and the lint-mr-mesg job just as my other jobs and stages. Maybe special consideration could be be given to these git-hook jobs in how they are displayed in MR such as the "ready to be merged automatically" message, but I don't even think that would be necessary.

Edited by 🤖 GitLab Bot 🤖