ci: adjust build arguments

[georglauterbach]

Description

The build arguments VCS_REF and VCS_VER were renamed and given proper values according to their names.

1. VCS_REVISION holds the current SHA sum of the (git) HEAD pointer
2. VCS_VERSION now holds the contents of the VERSION file, i.e. a semver version tag (one can now inspect the image and find a proper version tag in the org.opencontainers.image.version label)

The build arguments were given defaults in order to allow the generic_build and generic_test workflows to omit them (as they are not need there anyways). When publishing images, this is fina as the cache will rebuild almost all of the image except the last few layers which are LABELs anyways.

Type of change

• Improvement (non-breaking change that does improve existing functionality)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[georglauterbach]

@polarathene just had a quick glance at CI, found this:

WARNING: local cache import at /tmp/.buildx-cache not found due to err: could not read /tmp/.buildx-cache/index.json: open /tmp/.buildx-cache/index.json: no such file or directory

Do you think we need to worry here? Everything seems to be working. This may only occur on the first run?

[polarathene]

Do you think we need to worry here? Everything seems to be working. This may only occur on the first run?

It looks fine, no cache was restored for the build job, so when it tries to look for the cache to restore during the "build image step" it has nothing to restore, and emits a warning about it, in case you expected cache to be there.

We see that it uploads the cache afterwards fine, and the test job restores that properly.

However, I don't think the job was meant to upload a new cache to cache-buildx-... This means that the input to provide the cache key is not being passed properly, it's empty! :( key: cache-buildx-${{ inputs.cache-key }}.

---

Build job:

Cache restore step:

Cache not found for input keys: cache-buildx-2029d15ef91c6c247e409eaeed24a3937450de9592b6655960507cea21fe5962, cache-buildx-

Build image step:

WARNING: local cache import at /tmp/.buildx-cache not found due to err: could not read /tmp/.buildx-cache/index.json: open /tmp/.buildx-cache/index.json: no such file or directory

Post cache upload step:

Cache Size: ~326 MB (342301600 B)
Cache saved successfully
Cache saved with key: cache-buildx-2029d15ef91c6c247e409eaeed24a3937450de9592b6655960507cea21fe5962

---

Test job:

Cache restore step:

Cache restored successfully
Cache restored from key: cache-buildx-2029d15ef91c6c247e409eaeed24a3937450de9592b6655960507cea21fe5962

Build image step:

#52 DONE 0.0s

Post cache upload step:

Cache Size: ~326 MB (342301398 B)
Cache saved successfully
Cache saved with key: cache-buildx-

[georglauterbach]

@polarathene I will have a look at the cache issue next week :)

[polarathene]

@georglauterbach alright, just keep in mind that any time a cache doesn't exist for the expected cache key, the fallback (restore key) is now cache-buildx-, which was meant to match any prior cache keys as a prefix, but probably gets a direct hit now (for about 7 days since it was created AFAIK).

Until it expires, a fix may not fallback correctly, but at least for the test job that shouldn't be an issue, the build job is always meant to make a valid cache key for a direct match.