1

Bitbucket, Github and other services tend to have a "push" hook, so that when you push code to the repository, the service can hit a url (possible on a production server), telling it to pull the latest code.

The problem is, if I have a number of servers in the cloud (which come in and out based on load), I do not have a way of knowing how many servers are in the cloud at any given time, so I cannot configure which urls to "push" to. Is there an alternative way?

Is there a way to instead have all the production servers hit a url on github, bitbucket etc, and check if they need to update ? This is not specific to any one service, because I imagine if any one service has it all of them will. I just don't know what the "feature" would be called.

Rahul Iyer
  • 19,924
  • 21
  • 96
  • 190

2 Answers2

1

Bitbucket, Github and other services tend to have a "push" hook

Actually, a Git repo hosting server will have another option with Git 2.10 (Q3 2016): push options.

See commit 3ac8703, commit f6a4e61, commit c714e45, commit 77a9745 (14 Jul 2016) by Stefan Beller (stefanbeller).
(Merged by Junio C Hamano -- gitster -- in commit cf27c79, 03 Aug 2016)

That feature was proposed in this thread:

Allow a user to pass information along a push to the pre/post-receive hook on the remote.

When using a remote that is more than just a plain Git host (e.g. Gerrit, Git{hub/lab}, etc) this may become more obvious: The (server backend specific) push options can instruct the server to:

  • open a pull request
  • send out emails asking for review
  • (un)trigger continuous integration
  • set priority for continuous integration (i.e. bots pushing may ask to be treated with lower priority compared to humans)
  • ...

Most of these actions can be done on the client side as well, but in these remote-centric workflows it is easier to do that on the remote, which is why we need to transport the information there.

More concrete examples:

  • When you want a change in Gerrit to be submitted to refs/heads/master, you push instead to a magic branch refs/for/master and Gerrit will create a change for you (similar to a pull request).
    Instead we could imagine that you push to a magical refs/heads/master with a push option "create-change".
  • When pushing to Gerrit you can already attach some of this information by adding a '%' followed by the parameter to the ref, i.e. when interacting with Gerrit it is possible to do things like1:
git push origin HEAD:refs/for/master%draft%topic=example%cc=jon.doe@xxxxxxxxxxx

This is not appealing to our users as it looks like hacks upon hacks to make it work.

It would read better if it was spelled as:

git push origin HEAD:refs/for/master \
  --push-option draft \
  --push-option topic=example \
  --push-option cc=jon.doe@xxxxxxxxxxx

(with a short form that is even easier to type, but this is is more intuitive already)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

The push event of a GitHub webhook allows for the repository server (GitHub) to contact repository clients (your servers in the cloud)

But if that doesn't work, you would have two approaches:

  • have one dedicated repo client (one dedicated server of yours) which would be contacted by this GitHub webhook, and would know which servers on the cloud are available and need to be contacted.
  • or switch to a pull approach where a server on the cloud periodically does a git pull, followed by a git push to a bare repo (still on the same cloud server): a post-receive hook on that bare repo can be triggered if the git push pushed anything at all (As I mentioned in the comments of "How to execute a command right after a fetch or pull command in git?").
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • instead of the second option I would create a bare mirror repository; in that case you would just `git fetch` instead of `git pull` and `git push` – Jonas Berlin Mar 17 '15 at 22:35
  • @JonasBerlin but is there a fetch hook? The all idea behind the git push is to be able to associate a post-receive hook. The goal is to be able to *trigger* something when a push is done on GitHub (in the absence of a push event listener mentioned in the first option) – VonC Mar 18 '15 at 06:21
  • Ok sorry I got sidetracked a bit. Yeah in that case I would reduce the second option to just `git pull` regularly; if some action needs to be taken in case there were changes, one could just `git rev-parse HEAD` before and after the pull and see if the output of that command changed. – Jonas Berlin Mar 18 '15 at 06:50
  • @JonasBerlin a manual pull trigger, then... I wished there was a native pull hook, but so far, no luck (http://stackoverflow.com/q/4185400/6309). – VonC Mar 18 '15 at 06:54