3

So, I'm aware of git hooks, and will be looking into those next, but want to write a simple bash script, run via cron, to keep a repo on a remote server up to date. I imagine it working like this:

  • cron executes myupdatescript.sh
  • myupdatescript.sh will:
    1. cd into /my/sites/staging
    2. git pull -q origin master
    3. if something was pulled, then:
      • run grunt to build the source
      • yadda yadda yadda

I currently have this working as a cron task that looks like:

*/1 * * * * cd /my/sites/staging && git pull -q origin master && grunt production

I'm trying to avoid having to run my grunt build if nothing changed. I guess it all boils down to how can I tell if git pull actually pulled anything, and use that as a condition to running my grunt build. Ubuntu server, key is installed on github, all that good stuff. Thanks for any help!

Jenny D
  • 27,780
  • 21
  • 75
  • 114
Greg
  • 231
  • 1
  • 3
  • 11
  • If you want to make some decision after git pull, you should remove the "-q" argument (quiet), so it actually writes to the console and you can grep it or something. – jotadepicas Oct 11 '19 at 19:50

3 Answers3

4

I think you can solve this issue simply doing it: 

*/1 * * * * cd /my/sites/staging && git pull -q origin master|grep -v "up-to-date" && grunt production
Daniele Siddi
  • 51
  • 2
  • hmm, shouldn't you remove the "-q" argument (quiet), so it actually writes "up-to-date" to the console and you can grep it? – jotadepicas Oct 11 '19 at 19:49
4

Both problems (automatically handling your deployments and avoiding useless work, e.g. running a grunt task if nothing changed) are what git hooks are for.

So my advice would be to get rid of cron tasks altogether and switch to managing your repositories via hooks as soon as possible.

The way this is usually done is described in detail here, and basically requires you to have a bare repository (a hub repo) to push to/pull from and a checked-out version of the same repo (a live repo) located in the appropriate path, say /srv/www/html, for example.

I like to use gitolite3 to handle the hub repo, but that is not a requirement, though it's rather convenient to have fine-grained access control bound to your LDAP of choice if needs be.

It is also a good practice to limit the capabilities of the gitolite3 user via sudo, and handle the hooks by means of sudo calls. This is a working example using gitolite3 hooks (feel free to adapt them -or enhance/fix them- to suit your needs):

  • hub repo post-update hook:

    #!/bin/sh

echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"

sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"

exit 0

  • publisher-hub2live script:

    #!/bin/sh

echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"

cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master

# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info

exit 0

  • A live repo post-commit hook can useful too, if you ever make changes in the checked-out working tree of the live repo and want to sync the hub.

This infrastructure requires the following entries (or equivalent ones) in your sudoers file:

Cmnd_Alias        GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3                ALL = (root)NOPASSWD: GITOLITE_CMDS

Also, a Match block in your sshd_config would be useful, depending on how you manage identity in your machines:

 Match Group gitolite3
  Banner /etc/issue.empty
  RequiredAuthentications2 publickey

With all this in place, pushing to the hub repo triggers the post-update hook, ensuring that your custom actions are executed only when there's something new .

dawud
  • 15,096
  • 3
  • 42
  • 61
0

While I've not used it myself from my understanding of puppet http://puppetlabs.com/ you can do this.

Each time puppet runs if something changes it will be pushed out to the other servers automagically based on what the gold image is. And if you have a large number of servers once you create the gold image you can create a base install puppet on another and the new server will get the rest of the config from the master server.

Douglas Francis
  • 83
  • 2
  • 9