As soon as I saw the YAML one-line snippet I knew it was a quoting issue.
My first thought was that git hash started with a zero, and the parser stripped it off because it was parsing it as a number and not a string.
But then I saw "infinity" and was like "wait is the git hash all numbers except there's the letter 'e' in there somewhere"?
Ugh.
Always quote your YAML strings!
I just wrote a configuration format writer for an app I maintain, The C libyaml library (ugh, yes, I have to write this in C) lets you specify the quoting style it will emit for strings... always choose some form of quoting.... always.
Also it seems kinda short-sighted for this company to use the short git hash. The short hash is nice for display purposes, but there's always the possibility of a collision (git is smart and will print out a revision that has no current collisions within your repo, but that doesn't mean it won't happen in the future). But for a configuration setting like that, there's really no reason not to use the full hash.
My first thought was that git hash started with a zero, and the parser stripped it off because it was parsing it as a number and not a string.
But then I saw "infinity" and was like "wait is the git hash all numbers except there's the letter 'e' in there somewhere"?
Ugh.
Always quote your YAML strings!
I just wrote a configuration format writer for an app I maintain, The C libyaml library (ugh, yes, I have to write this in C) lets you specify the quoting style it will emit for strings... always choose some form of quoting.... always.
Also it seems kinda short-sighted for this company to use the short git hash. The short hash is nice for display purposes, but there's always the possibility of a collision (git is smart and will print out a revision that has no current collisions within your repo, but that doesn't mean it won't happen in the future). But for a configuration setting like that, there's really no reason not to use the full hash.