Hopefully today I’ll be able to knock this out and get rid of that extra commit in the cross merge. I wish I built this a while ago. While searching for prior work I ventured across bats which looks promising. I’m not sure it will work for what really amount to integration/system tests though. That framework will need to wait for a future endevor then.

For diagnostics I’m hoping git log --pretty=format:"%h %s" --all --graph will be a life saver.

In the origianl desing of the release process I made the assumption the system will also have remotes for each release branch. I don’t see why this would be otherwise so I’m going to stick with that assumption but warn users otherwise. There is an exception in the testing case, primarily because I don’t want to create multiple repositories in Github or another remote to merely represent the states under test. Since Git will error out if there aren’t remotes configured when you pull the following will get around this issue:

    remote_tracking_count=`git config branch.$TARGET_BRANCH.name|wc -l`
    if [ $remote_tracking_count = 1 ] ; then
      git pull
    else
      echo "${sm}WARNING: $TARGET_BRANCH is not configured to track a remote.${sn}"
    fi

Of course this is in the local context of the $TARGET_BRANCH; assuming it’s already been checked out. I look forward to a more elegant solution.

Up next on the list of challenges is how to change a specific line within a single file. This will simulate the actual modification of the version number within the release process. Sometimes I wonder if using Git hashes for versioning would be easier but it would remove the primary advantage to a system where people can rationalize the releases.

So many other activites over the day.