* * * * *

              It shouldn't be this hard to deploy a new version

I spent more time fighting git and Github [1] than I did in writing the code
to support the JSON Feed [2]. 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 [3] 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:

-----[ Makefile ]-----
VERSION := $(shell git describe --tag)

..

override CFLAGS  +=-DPROG_VERSION='"$(VERSION)"'
-----[ END OF LINE ]-----

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 [4]?

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:

-----[ shell ]-----
GenericUnixPrompt> git tag -d 12345
GenericUnixPrompt> git push origin :refs/tags/12345
-----[ END OF LINE ]-----

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 [5] file.

[1] https://github.com/
[2] gopher://gopher.conman.org/0Phlog:2017/11/13.1
[3] https://github.com/spc476/mod_blog
[4] https://www.urbandictionary.com/define.php?term=wat
[5] https://boston.conman.org/index.json

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.