build.go: validate -version argument against regex from lib/build

[gudvinr]

In #9267 it was mentioned that binaries built with incompatible versions can't be run.
To avoid situations like this completely, same regex is used to validate manually provided versions.

[gudvinr]

Huh, some tests are already failing. That's interesting.

I don't know much about CI pipeline but it seems like git describe in getGitVersion only returns commit hash for some reason

[calmh]

Right, so it is, because the builds there do a shallow checkout. I added an exception for unknown-dev (which happens when there is no git at all), before seeing this.

Of course, disallowing the just-a-hash "versions" is correct, that's part of why we do this check to begin with. I guess options to fix it is to do full checkouts in more places in github actions, or have getVersion() return unknown-dev when it's just a hash...

[gudvinr]

I guess options to fix it is to do full checkouts in more places in github actions, or have getVersion() return unknown-dev when it's just a hash

I think it depends on how resulting build are used. If it's just to test compilation then unknown-dev is good enough for cases when it's not possible to determine version tag.

When build artifacts then used for packaging, then build process should be fixed. I don't think it's the case because production builds don't fail AFAIK.
However, it's still might be useful for external builds. E.g. linux packages built by distro maintainers. If git hash will be masked by "unknown-dev", it won't be noticed until after someone runs an app and checks version.

[calmh]

Perhaps a third option is to generate something like v0.0.0-g32cca86ac or v0.0.0-dev+g32cca86ac, which is acceptable to all the regexps, clearly shows that something funky happened during the build, and yet is identifiable if encountered in the wild...

Indeed we don't produce binaries like this (and hopefully nobody else either), but being able to run tests without knowing the correct version number might be useful.

[gudvinr]

Perhaps a third option is to generate something like v0.0.0-g32cca86ac or v0.0.0-dev+g32cca86ac, which is acceptable to all the regexps, clearly shows that something funky happened during the build, and yet is identifiable if encountered in the wild...

I'd suggest to add a check in runtime that will send a log message and visible warning in UI for unknown-dev version string specifically. That'll be a clear signal to users (or maintainers) that they messed up in build preparation. At the same time it shouldn't be an issue for official packages. And CI shouldn't care about that.