Create versioned symlinks to output images

[sam-aws]

Issue #, if available:
N/A

Description of changes:
On build success create symlinks to the Thar output images, with a
arch-flavor-version format. The version is relative to the latest git
tag if available or the current date as a fallback. Old symlinks are
cleaned up to avoid confusion.

For example, build of tag:
thar-x86_64-aws-k8s-v0.1.5-boot.ext4.lz4
Development build, unclean tree:
thar-x86_64-aws-k8s-v0.1.5-51-g04cf58b-dirty-boot.ext4.lz4

Signed-off-by: Samuel Mendoza-Jonas [email protected]

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sam-aws]

Updated to remove any old links before the build starts, so there are no incorrect links hanging around if a build fails.

[tjkirch]

So that it doesn't look like this PR is just hanging, I wanted to mention discussion that's happened elsewhere. One question was whether the links should be named like this PR suggests or if the build artifacts themselves should be named like this, perhaps with links that have the current, more generic names. Another question was one of motivation, which has been discussed outside but isn't laid out in the PR - documenting that might help move things along, too.

[sam-aws]

Another question was one of motivation

Following up on this one, the overall motivation is to take versioning out of human hands and have it be automatically generated where needed. This PR is a start at using the information that git tags give us; future PRs would extend this and use git describe --tag --dirty to automatically set the version in /etc/os-release and other areas. This helps to:

• Avoid forgetting to increment the version in release.spec
• Prevent two very different images from reporting the same version; VERSION_ID would show the number of patches since the last tag
• Allow exact version-matching when creating a build for release, catching builds with extra commits or dirty build trees
• Make determining datastore changes and migrations required since the "last" release easier and/or automatic.

[sam-aws]

if the build artifacts themselves should be named like this

On this point I'm pretty neutral; one thought I did have was that if the build system were to fail but produce some part of the build artifacts, then if the symlinks are versioned they are only created after complete success. But that's getting pretty nit-picky :)

[tjkirch]

if the build system were to fail but produce some part of the build artifacts, then if the symlinks are versioned they are only created after complete success

On the flip side, if a build were to fail, there might be versioned links pointing to some new artifacts and some old. I think it's difficult to be 100% confident that links are pointing to the right files if the files themselves aren't versioned.

[sam-aws]

In the current incarnation links are cleaned up before the build and only added after foo-images and check-licenses are complete, so I don't think there's that risk unless Cargo drops the ball on dependency ordering.

[tjkirch]

the overall motivation is to take versioning out of human hands and have it be automatically generated where needed

I agree with the overall goals. I think we get those benefits whether the files or links are versioned, though. I still feel that we should name artifacts rather than links, and I hope we change, but I'm willing to go along with this so we can keep moving toward the other benefits.

[sam-aws]

I'll merge this to get things moving, and we can revisit when building up the rest of the release/infra bits 👍