Stupid bash tricks: a self-updating script

For a demo app, I want a simple-as-possible deploy script. The simplest thing is to hard-code the version number (which gives my docker image a unique tag, which gets kubernetes to pull the new image1).

But I’m tired of updating the version number. So I made the script update it for me.

Why not use a real deployment system, Jess? I don’t want to. Some abstractions are out of scope for a freaking demo that nobody is allowed to deploy but me.

Here is the script, with the deployment part stripped out, that updates itself to increment the version number for the next run. (also as a gist)

#!/bin/sh

me=$0 # name of this script

VERSION_NUMBER=5

## Do stuff with the version number
echo "I am $me, with version number $VERSION_NUMBER"

## Now change this script to increment the version number
## so next time it will be different.
function sed_in_place {
  expr=$1
  file=$2
  backup=$file.bak
  sed "$expr" $file > $file.bak
  # next, copy the file permissions
  chmod `stat -f %A $file` $file.bak # this works on mac
  mv $file.bak $file
}

sed_in_place "s/VERSION_NUMBER=$VERSION_NUMBER/VERSION_NUMBER=$(( VERSION_NUMBER + 1 ))/" $me

After running this, I’m left with a changed file in my git repository. Oh well, it gets lumped into the next commit. If I wanted to this _right_ I’d put it in CI. But that would add time to each deploy, and I’m gonna be live-coding this during a 60m presentation. “Dead simple and fast” is more useful to me than any “best practice.”

  1. Yes, I have the kubernetes deployment set to “always pull” and it even says “pulling image” in the event log, but did it get the new code? no. That is not the fight I am fighting today.

Discover more from Jessitron

Subscribe now to keep reading and get access to the full archive.

Continue reading