Integration test for docker buildx version

[jsternberg]

An integration test for docker buildx version has been created. The
integration test checks that there is one line output, the output is
composed of three sections, and that these sections could feasibly be
the package path, version, and revision information.

The intention of the checks is to find obvious errors in the output like
the package path not existing or the version and revision being swapped.
It is not intended to assert that these values must be certain values
because it is assumed these values may vary depending on the build
process for buildx.

Related to #1857.

[crazy-max]

It seems to make sense that version is not semver when running tests. We use git describe to set the version:

buildx/hack/git-meta

Line 7 in c010d3d

git describe --match 'v[0-9]*' --dirty='.m' --always --tags

And looking at the GHA workflow:

buildx/.github/workflows/build.yml

Lines 78 to 80 in c010d3d

	-
	name: Checkout
	uses: actions/checkout@v3

We don't fetch tags so only commit sha will be returned. It should work if you set:

      -
        name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

See https://github.com/actions/checkout/#usage

# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''

[crazy-max]

If we don't need to bump to v0.12.0, can you just keep v0.9.0? But if needed then can you do the vendoring in a dedicated commit?

[jsternberg]

Yea I can throw this back down to v0.9.0. I figured it was likely at v0.9.0 because it was an implicit dependency, but it's likely better to just do any version upgrades as a different PR anyway.

[thaJeztah]

Perhaps we should check that the last element is the version, and not necessarily that there's 3 components (and exactly one line); https://www.gnu.org/prep/standards/html_node/_002d_002dversion.html#g_t_002d_002dversion

ideally the middle part (packaging info) would be between brackets, but at least convention / guidelines (see above, although admitted that is for --version) is the last element of the first line to be the version.

The output may have multiple lines, which can be used to print (e.g.) licensing info / notices

[jedevc]

@jsternberg just a small note - I tend to avoid trying to include PR/issue numbers in commits, just since GitHub chooses to then spam these quite heavily into those issue descriptions 😢 (see in #1857)

[jsternberg]

@jedevc yea I was wondering about that. I'll remove it. The merge commit should have the github pull request number which could then get traced back to the original PR and I can keep the issue description in the PR itself so it doesn't spam.

[jsternberg]

@thaJeztah I think changing the check to follow the standard set by GNU would be fine although it seems our current output prints the revision last when it's available so we'd probably just need to check "is there something that looks like a version in the first line?"

I do think there's some value in making the check a bit more strict though. There may be people potentially using the output for some reason and, while the output is likely not listed as stable, we shouldn't change it accidentally. I also think there's some value in the test breaking if the output changes drastically and then fixing the test to compensate.

I do also think that testing that the output is a single line might be a bit aggressive. I think I should remove that.