Andy Balaam from Andy Balaam's Blog
Here is the talk CB Bailey and I did at ACCU Conference 2019. This was the first talk I have done with someone else, and I really enjoyed it:
Andy Balaam from Andy Balaam's Blog
Here is the talk CB Bailey and I did at ACCU Conference 2019. This was the first talk I have done with someone else, and I really enjoyed it:
Andy Balaam from Andy Balaam's Blog
Today I wanted to fix a Git repo that contained some bad commits (i.e. git fsck complained about them). [I wanted to do this because GitLab was not allowing me to push the bad commits.]
I wanted the code to look exactly as it did before, but the history to look different, so the bad commits disappeared, and (presumably) the work done in the bad commits to look like it was done in the commits following them.
Here’s what I ran:
git filter-branch -f --commit-filter ' if [ "${GIT_COMMIT}" = "abdcef012345abcdef012345etcetcetc" ]; then echo "Skipping GIT_COMMIT=${GIT_COMMIT}" >&2; skip_commit "$@"; else git commit-tree "$@"; fi ' --tag-name-filter cat -- --all
(Where abdcef012345abcdef012345etcetcetc was the ID of the commit I wanted to delete.)
Of course, you can make this cleverer to exclude multiple commits at a time, or run this several times, putting in the right commit ID each time.
Andy Balaam from Andy Balaam's Blog
For when git status is not enough, I wrote git what:
If you often have a few branches on the go, it could be useful.
We have a prototypical webapp platform which has four variants, commodities, energy, minerals and wood. We use the Maven war overlay feature. Don't blame me it was before my time.
This architecture, with a core platform and four variants, means that one commit to platform can result in five staging sites needing to be redeployed.
We have a fairly mature Continuous Integration setup, using Jenkins to build five projects on commit. The team is small enough that we also build each developer's fork. Broken builds on trunk are not common.
NB This setup does deploy broken builds. Use a pipeline if broken staging builds are a problem in themselves.
Of Martin Fowler's Continuous Integration Checklist we have a score in every category but one:
Each project has an executable build file redo:
which calls the deployment to tomcat reload
mvn clean install -DskipTests=true
sudo ./reload
We can use a githook to call redo when the project is updated:
service tomcat7 stop
rm -rf /var/lib/tomcat7/webapps/ROOT
cp target/ROOT.war /var/lib/tomcat7/webapps/
service tomcat7 start
cd .git/hooks
ln -s ../../redo post-merge
Add a line to chrontab using crontab -e
This polls for changes to the project code every five minutes and calls redo if a change is detected.
*/5 * * * * cd checkout/commodities && git pull -q origin master
However we also need to redeploy if a change is made to the prototype, platform.
We can achieve this with a script continuousDeployment
which is also invoked by a crontab:
#!/bin/bash
# Assumed to be invoked from derivative project which contains script redo
pwd=`pwd`
cd ../platform
git fetch > change_log.txt 2>&1
if [ -s change_log.txt ]
then
# Installs by fireing githook post-merge
git pull origin master
cd $pwd
./redo
fi
rm change_log.txt
*/5 * * * * cd checkout/commodities && ../platform/continuousDeployment