Update tags for image based solely on image content

[deitch]

We currently tag images using the git hash, and include the version in the binary using go build ... -X "$(PACKAGE_NAME)/pkg/version.VERSION=$(VERSION)"', using a $VERSION that is <tag-if-on-this-commit>-<git_hash>

<git_hash> is provided by git log -1 --format="%h".

The problem with this is that the git hash is affected by any changes to the repository, not just to the code that affects the built image. The actual code affecting the image is:

• go.mod/go.sum
• any *.go files (basically in pkg/ and cmd/)
• Dockerfile.*
• potentially Makefile

By just taking the last commit hash, we create an infinite loop trying to put the actual hash in the deploy yml files, e.g., because those files will have a hash in them that is the one from the PR's last commit, not the merge commit.

We need to try to make the actual image tag more predictable.

There is a number of ways to do this:

• Accept it as is, knowing that the tags might be a bit behind
• Use the tree hash rather than the git commit
• Leave this as is, but move deploy yml to entirely different repository

[displague]

Accept it as is, knowing that the tags might be a bit behind

This is the case today. (1.1.0 != 1.0.0):
https://github.com/packethost/csi-packet/blob/v1.1.0/deploy/kubernetes/controller.yaml#L65

We currently tag images using the git hash, and include the version in the binary using ...

Have we documented why we are taking that approach?

Should we also consider removing the Git hash from images? I don't think the hash creates many problems for the master branch builds, but if it does, perhaps images based on this branch could be tagged canary or latest.

If we rely on SemVer (and git describe), omitting the hash, we can predict the version of the image that we want to include in the released .yml files.

I've created #84 to prevent the detected version mismatch problem. It seems that this issue will influence #84.

I don't see a way to fix the version mismatch in 1.1.0 since it is tagged, but we can make sure we don't recreate that problem in 1.1.1 (or 1.2.0).

[displague]

Will not fix - see #103 (Equinix Metal Block Storage from Datera is EOL).