Skip to content

Instantly share code, notes, and snippets.

@bryanwb
Created July 22, 2012 15:11
Show Gist options
  • Save bryanwb/3159952 to your computer and use it in GitHub Desktop.
Save bryanwb/3159952 to your computer and use it in GitHub Desktop.

Question

A customer inquired about server-side pre-receive git hooks. You notified them that GitHub Enterprise does not currently support those. They then respond as follows:

I am afraid this won't do unless you have a pretty immediate solution.

We currently have 2 pre-receive hooks in place that we need to port over to the new enterprise server or we just won't do the migration.

We currently do 2 things before we let users commit, 1 we check if they have a valid email "@acme.com", we also have a workflow that does not allow anyone besides the release engineering to check into the master branch of any of our repositories, this ensures that our master branch is always what is currently in production.

What workaround would you offer them in this situation?

Answer

I will assume that the second requirement is far more critical than the first. It is not clear to me if requirement is meant to keep non-Acme employees from submitting changes to the repository. However, someone could fake an @acme e-mail address very easily.

I would also investigate whether I could use an update hook in place of the pre-receive hooks in both of these cases. However, I suspect that if the enterprise product does not support the pre-receive hooks then there is a good chance that it does not support the "update" script either.

The pre-receive commit hook that checks for a valid e-mail address could be replaced with a pre-commit hook. This could easily be disabled by a developer but I assume here that the developers have little interest in hiding their e-mail addresses.

For the second requirement, I suggest separating the release engineering team into their own organization. The developers will have to fork all of the repositories residing in the release engineering team. The developers will be able to commit to master within their organization. They must send pull requests in order to get their commits into the release_engineering organizations.

Note: It will take some time to convince the customer that committing to the master branch of acme_developers/foobar is distinct from committing to the master branch of acme_release_engineering/fooba.

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