Include build-version in artifact names

[jwodder]

Closes #61.

[jwodder]

@yarikoptic Is it necessary for the Linux build steps to clone git-annex into a directory in /tmp? Getting the version would be a lot cleaner if the code was checked out to the same place on Linux and macOS. Moreover, is the build_git_annex script ever used outside of the GitHub Actions workflow, or can I make some simplifications based on the assumption it'll only ever be run in a workflow?

[jwodder]

@yarikoptic @joeyh What is the recommended way to get just the git-annex version when building? With Windows, I captured the output from ./Build/BuildVersion, but getting that to work on macOS will require some rewrites that will likely involve splitting the workflow into two separate workflows, one per OS — and I don't know how to make this work on Linux without either duplicating steps or else eliminating the use of Singularity.

[yarikoptic]

sorry to be a pain, but IIRC that dist/build-version which annex produces is "subopimal":

$> Build/BuildVersion
8.20201008-ga3bb6f235% 

so it is not sortable at all. That is why we should not use it for "our" (this one is what what @joeyh wants/uses, so we just include that produced artifact) version, which should be based on the output of git describe:

$> git describe
8.20201007-145-ga3bb6f235

but with a slight tune up (my personal convention I guess)

$> git describe | sed -e 's,-,+git,' 
8.20201007+git145-ga3bb6f235

which makes it a bit more obvious what is that version about (git still understands it since looks only for -g suffix with hexsha).
And then artifact name should include architecture. E.g. in http://datasets.datalad.org/datalad/packages/windows/ I added _x64 since felt that is what windows folks got used to, although in case of a debian package should be _amd64 (it is no longer "amd" but that is what debian uses, heh).

[jwodder]

Is using the output of uname -p as the architecture acceptable, or should it be specifically _x64 for Windows, _amd64 for Linux, and ... what? ... for macOS?

[yarikoptic]

well, for "debian" (current only Linux) if to be specific, should be output of

$> dpkg --print-architecture
amd64

ran within that singularity env. And if I download that .zip with artifacts, I see that we do have version already nicely set for that .deb:

$> unzip git-annex-debianstandalone-packages.zip 
Archive:  git-annex-debianstandalone-packages.zip
  inflating: git-annex-build.log     
  inflating: git-annex-standalone_8.20201007+git145-ga3bb6f235-1~ndall+1_amd64.deb  
...

no tune up needed for it at all, and may be you could just take that version altogether from the name of the .deb file?

For Windows and Mac -- I have no personal preference really. uname -p under git shell on windows tells me "unknown" though.

[yarikoptic]

@yarikoptic Is it necessary for the Linux build steps to clone git-annex into a directory in /tmp? Getting the version would be a lot cleaner if the code was checked out to the same place on Linux and macOS.

I do not think it is necessary, unless it all fails and may be git blame on the original commit which added it provides some explanation? yes -- I would vote for as much of uniformity as possible ;) since for linux singularity involved, I believe I might have just gone for /tmp since it is bind mounted automagically, but so should also be the current directory as well. So try without dealing with /tmp -- may be it would just work.

[yarikoptic]

eh, I said that I do not care about OSX, but saw _i386 and got all "touchy" ;) But it is all green which is awesome and I saw all those versioned artifacts... before asking for any changes, I will try to figure out what we actually should do. uname -m (x86_64) seems to be the closest call, but in general asking kernel is not the right thing to do -- the same x86_64 could build both 32 and 64 bit versions, and even cross-build into other architectures... and _ in it throws off my convention of name_version_build.ext. if we know that it is 64bit ATM for OSX, we should may be just hardcode consistently with windows into _x64 and be done and consistent between those two. Or better ideas?

[yarikoptic]

@jwodder , please

• fix it up so _ not - used to separate name from version in name_version_arch.ext (ATM it is e.g. git-annex-macos-dmg-8.20201007+git145-ga3bb6f235_i386.zip)
• "hardcode" _x64 for windows and mac. At least it is listed "also known as" for x86_64 on https://en.wikipedia.org/wiki/X86-64 so not too adhoc.

[jwodder]

Version suffixes adjusted.

[yarikoptic]

Results look great to me! May be with time we would somehow minimize duplication through workflows, but meanwhile -- thank you very much @jwodder . If you are yourself satisfied, please take it from the Draft mode and let's have it merged. Then let's fixup for OSX to get tests passing -- DataLad release(s) are coming up so we would be right in time! ;)