Add hooks to source scripts before and after setup

[mdelillo]

We would like to use this repo without forking it, so this PR adds hooks so that we can execute scripts before and after running the setup. If $HOME/.pivotal-workstation-pre-setup and/or $HOME/.pivotal-workstation-post-setup, scripts in them will be executed before and after the bulk of setup.sh.

Also, fixes git status alias.

[professor]

Hi @mdelillo -- what a few teams do is have a readme that says 1) run workstation-setup 2) run a team script that makes additional modifications

In this situation, there's no need to fork this repo.

I'd like to hear from others if they would see value in baking in pre, post hooks.

[mdelillo]

A small win for us is that we can combine those two steps into just running our team script, which means we can run a single command and walk away for awhile when setting up a new workstation.

The specific problem we were encountering with separate scripts is that we want to run things that require sudo before and after running the setup.sh script. We couldn't find a solution that didn't require typing in the sudo password more than once without introducing these hooks.

[professor]

@nertzy and I discussed this PR. Normally we would expect a team to run a team script after workstation setup to finish any team specific customizations. As such, it would be fine for that team script to call the workstation setup script. In this case, there is no need for any pre or post hooks.

#!/usr/bin/env bash
team setup stuff
pushd workstation-setup
./setup.sh
popd
more team setup stuff

If other teams are wanting the feature described in this PR, let us know. Thanks for understanding @mdelillo

[mdelillo]

@professor @nertzy that's fair, and that is how we are using it for the most part.

Taking a step back, the original problem we are trying to solve is that we had to type the sudo password multiple times when running setup.sh. The script takes long enough to run that the password gets uncached. We have a script we run before setup.sh that extends the timeout in /etc/sudoers, but that itself needs the password to be cached. It is later reset here, requiring it to be typed again.

Another way we could go about solving this would be to only prompt for the password if it isn't cached. Something along the lines of this could work:

if ! sudo -nv 2>/dev/null; then
  sudo -K
  sudo true
fi

If you are open to something like that (or even modifying the sudoers file itself, but I'm not sure that's a great solution), I'd be happy to update this PR or make a new one.

Thanks!

[joemoore]

We are declaring PR bankruptcy as per #295.

Please review recent changes and direction and resubmit if needed.

Thank you!