It would be easy with a simple post-receive hook, but it would not be good solution to the ultimate problem.
When developer commits change to the UI, they should also update the tests so they pass again in the same commit or at least in the same push. That means the tests should be in the same repository as the code. Well, since they are intimately tied with the way the UI works, they should.
Then it's just a matter of using Continuous Integration (I am used to Jenkins; there are other options too) and/or automatically deploying the changes to the test environment against which the tests run (see e.g. Deploy a project using Git push).
That said, you can do it with hooks.
First, to find whether any *.jsp
files have been changed between revisions $old
and $new
you call:
git diff --exit-code --quiet $old..$new -- '*.jsp'
and if exits with false (non-zero) status, then some have changed (without the --quiet
it will show you the changes, with --name-status
it will list the files).
So now you just need to put something like
while read old new ref
do
if !git diff --exit-code --quiet $old..$new -- '*.jsp'
then
git diff --name-status $old $new | \
mail -s "*.jsp files changed in $ref" \
you@company.com
fi
done
to post-receive hook in your repository.
Or you could adjust the command to prevent developers pushing *.jsp
files directly to master
(e.g. via gitolite) to force them to push such changes to some staging branch where the automation will be updated by the other team and only then integrated by the other team or designated gatekeeper.