Monday, November 13, 2017
It shouldn't be this hard to deploy a new version
I spent more time fighting git and Github than I did in writing the code to support the
JSON Feed.
Yeah,
the code was straightforward and I had it done rather quickly.
Deploying the code was something else entirely.
So I finished the code,
and the new templates to generate the feed and my tests were good and life was fine.
I then committed my changes to git and that's where the first problem occured—not all the changes were committed!
The issue came down to an overbroad directive to git to ignore a certain file—it
was a general “ignore all files of the given name” instead of “ignore this one file” that I forgot about.
So I tagged the release (version 5.0.0),
pushed the changes to Github
(for public consumption of the source code)
and then went to update the copy of mod_blog on the server.
It was there when I discovered the critical missing file (one of the templates for the new JSON Feed).
Sigh.
I had been a bit too hasty in pushing the code out to Github,
so now I was stuck with releasing version 5.0.1.
Only now something got munged up with my copy of the code on the server since it compiled the program with a version number of 5.0.0-1-gd096362
instead of a version number of 5.0.1.
A bit of background: I use git to tag versions,
and in the Makefile I have the following bit of code:
VERSION := $(shell git describe --tag) ... override CFLAGS +=-DPROG_VERSION='"$(VERSION)"'
so I don't have to update the version number in code by hand
(the override exists so I can specify different compiler flags and still have the version information propagated to the program;
I also handle the case when git isn't available,
but that comes in later in my tale of woe).
Running git tag showed a tag of 5.0.1,
but git describe --tag was only coming up with 5.0.0-1-gd096362.
Wat?
Did I not update things properly?
Was it a problem with the version of git on the server?
Did I lose the signal?
Was it lost in translation?
Wat?
Some quick changes,
try version 5.0.2.
That worked—kind of.
Now on the server the version was reporting back version 5.0.1.
Then I discovered another issue.
I have code in the Makefile to handle the case when the version number isn't available through git—it's just
a check to see if git describe --tag returned anything and if not,
use a hard coded version specified in the Makefile.
Now,
to prevent me from pushing an update to Github with an incorrect version number in the Makefile,
I have a script that is supposed to run when I push changes to Github
(specifically, when I push changes to a remote host).
Only the last change to that script rendered it non-executable,
so it wasn't running.
The version on Github had the wrong version number specified in the Makefile,
and I was still having this weird “one version back” problem on the server.
I was still having problems with version 5.0.3 when I gave up.
I wanted a nice, clean, 5.0.0 release,
and instead,
I was on my way to version 5.0.137 the way things were going.
And all because I didn't check in a critical file because of a typo.
If only I hadn't pushed the code to Github so quickly.
If only there were a way to remove the tagged versions from Github,
but there didn't seem to be an obvious way to me.
As I eventually found out, there was a way—from the command line on my development machine, I just had to run this blindingly obvious sequence of commands:
GenericUnixPrompt> git tag -d 12345 GenericUnixPrompt> git push origin :refs/tags/12345
Obvious.
I'm surprised I didn't realize that sooner.
So I removed the tags for versions 5.0.3, 5.0.2, 5.0.1, and 5.0.0,
made sure I had all the files and whatnot,
and re-released version 5.0.0.
Good Lord!
So now all is right with the world, and I have a new JSON Feed file.
