Reproducible builds

[imiric]

As mentioned in #1247 and #1245 (comment), we'd like our binary builds to be reproducible/deterministic, so that the same set of inputs produces the same bit-for-bit binary output.

Feature Description

This would give the assurance that building from a specific commit produces the same binary as the one released publicly. In case of the Dockerfile build, it would guarantee that the binary in the Docker image is exactly the same as the one built by build-release.sh.

Suggested Solution (optional)

Right now we use the go build -trimpath flag which helps:
https://github.com/k6io/k6/blob/14c6cd9f0a8e1923a1dc8aebf304bbeffd58581e/build-release.sh#L19
https://github.com/k6io/k6/blob/14c6cd9f0a8e1923a1dc8aebf304bbeffd58581e/Dockerfile#L5

... but it likely doesn't work since we inject a date in the version string:
https://github.com/k6io/k6/blob/14c6cd9f0a8e1923a1dc8aebf304bbeffd58581e/build-release.sh#L12

So maybe this date should be set beforehand and shared for both the Dockerfile and build-release.sh? I doubt we want to get rid of it entirely since it's very convenient to have in the version string.

[na--]

Instead of the build date, we can use the date of the git tag: https://stackoverflow.com/questions/13208734/get-the-time-and-date-of-git-tags/13208830

[joanlopez]

As discussed in #1997, the k6 version output no longer includes the date, and the VERSION_DETAILS pointed out in the issue's description is no longer used. So, considering that we already have -trimpath in-place, as stated above, and that, as far as I know, there's no other temporal reference, I think we can consider this as solved.

If you find any other aspect of the resulting binary that varies over builds, and that would be nice to get rid of, for the sake of consistency/reproducibility, please open another issue.

Thanks! 🙇