Code: Select all
commit = check_output(["git", "show", "-s", "--format=%h", "HEAD"]).strip() timestamp = float(check_output(["git", "show", "-s", "--format=%ct", "HEAD"]).strip()) build_no = ".".join([datetime.utcfromtimestamp(timestamp).strftime("%Y-%m-%d"), commit])
Code: Select all
build_no = check_output(['git', 'show', '-s', '--format=%cd.%h', '--date=short', 'HEAD'], shell=False).strip()
My first concern was that the "git show" command might convert the committer date to local time, which of course would have resulted in possible different build numbers, depending on the time zone of the computer on which a build is produced. However, this isn't the case, as the "git show" command returns the timestamp in the local time of the original committer. Which in turn creates another problem: If, for example, Dilvish (who is at -0700) makes a commit 2 hours after me (I'm at +0200, so 9 hours ahead), his commit, although the later one, has an "earlier" timestamp. Resulting in a possibly "lower" build number for the later commit.
That of course defeats the whole point of composing our build number the way it's done now, which is to have consecutive, incremental build numbers. Therefore, as a quick solution, I suggest to revert back to the original implementation which converts the timestamp to UTC before using it for the build number. This should take care of the issue.
I've created a PR with the respective changes.
But this issue illustrates quite nicely that using a date as build number isn't the most brilliant idea I ever had (Marcel and I had a brief exchange about that via PM). So I'm once again looking for a better way to compose our build number. Suggestions welcome, the best I've come up so far is the following:
Tag the very first commit of the repo with an annotated tag like "build-no-base" and simply use "git describe --match build-no-base" to get the total number of commits. Use this as the first part of the build number, and the hash as the second part (like it's already done now).