New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version: come up with good default implementation #81
Comments
If others want to see what's available, you can try: diff --git a/version/version.go b/version/version.go
index 1bc61d6..3a2562e 100644
--- a/version/version.go
+++ b/version/version.go
@@ -7,5 +7,24 @@
// Package version provides the version that the binary was built at.
package version
-const LONG = "LONGVER-TODO"
-const SHORT = "SHORTVER-TODO"
+import (
+ "fmt"
+ "os"
+
+ "rsc.io/goversion/version"
+)
+
+var LONG = "VERSION-UNKNOWN"
+var SHORT = "VERSION-UNKNOWN"
+
+func init() {
+ n, err := os.Executable()
+ if err != nil {
+ return
+ }
+ v, err := version.ReadExe(n)
+ if err != nil {
+ println(err.Error())
+ }
+ println(fmt.Sprintf("Version: %+v\n", v))
+} Then |
I'm getting an increasing number of inquiries about this in the context of OSS packaging in distros. It's a problem that we can't ship sensible version info if you're building from just the OSS repo. I'm going to take a swing at fixing this ahead of the Go compiler providing us more useful information, at least well enough that distro packagers can embed version info as they build, while we can continue to provide corp version info for the non-free programs. |
What's your plan? |
Rough plan, not tested out yet:
Works in the following use cases:
That's the general shower thoughts I had this morning. The context is that I reviewed the initial Nix/NixOS derivations for Tailscale last night, which are going to ship to NixOS users with the crappy fallbackversion info. Separately this morning, an Arch user pointed out that some of my AUR packages violate AUR convention by shipping binaries, and I need to switch to building from source - which would force me to implement some "version for OSS" hack anyway. Given those, I want to solve that problem ONCE AND FOR ALL upstream, so I can give downstream distro packagers uniform instructions for how to build binaries with good version data. |
So, another bespoke Makefile / make.bash / make.go for oss. (golang/go#37475) That's fine for now, for people who want to use it. I have a crazier idea for the |
Pretty much, yeah. It's definitely not what I want to do, but the third-party distros need something to embed version information we can reason about for debugging. A versioning service sounds interesting, though I question whether you can actually account for the variety of weirdery out there (e.g. all Nix binaries have altered library load paths and whatnots, so the compilers are likely to produce slightly different output). I think it's possible, but it'd be fiddly. |
Yo, This issue has been silent since March and assigned a low priority. But with the release of version 1.0 I think you need to reconsider. Today if I want to download
I can checkout the 1.0.5 tag, and try build it with What are the major roadblocks for embedding version information, and streamlining the build process? It would help reproducible builds for your project and distro packagers (semi-relevant as I'm interested distributing tailscale in the |
This got blocked on golang/go#37475 which is accepted but not yet implemented in upstream Go. Our I would suggest solutions but I'm not sure your goal. You mentioned several somewhat separate concerns. Our builds don't contain anything closed-source mixed in from the parent repo other than the version string, so if you set that, use For Arch builds, I'd just make the version be "1.0.5-g |
My goal is to have tailscale reproducible. This is important both when distributing binaries with no signatures, and for packagers to have a streamlined build process. My impression was that this versioning problem was the reason why I can't have a
So I tried. I fetched https://github.com/tailscale/go/releases/tag/build-56db76510f9640d2ad652f206ae6e41c1a5d63ca which is what
I don't know how the bootstrapping process affects the results, and I'm unsure if it's feasibly without you redistributing the compiler itself (what guarantees does the go compiler have?). Please do point out if I have made any mistakes with this, I'm just guessing my way around at this point. I think this is a problem, but I'm unsure if it's related to this issue specifically. Currently there doesn't seem to be a good way to prove how the distributed tailscale is being built. |
I think we supply some specific build tags too nowadays, right?
|
Oh, we also set the Relevant bits from our build system:
|
(This is all pretty off topic for this issue, though.) |
(Thanks,!I'm aware it's offtopic. I'm happy to take up this discussion wherever appropriate.) |
If you like Slack, see https://github.com/tailscale/tailscale/wiki/Community for a link. Otherwise if you prefer GitHub, just create a new issue here? Perhaps titled "Document how to generate the same binaries Tailscale distributes" |
I think the main intent of this issue has been addressed by https://github.com/tailscale/tailscale/blob/main/build_dist.sh |
https://go-review.googlesource.com/c/go/+/353930 will embed the git hash into generated binaries. I think that will be sufficient to cover the remaining case of concern in this issue, of people building from source. |
Temporary measure until we switch to Go 1.18. $ go run ./cmd/tailscale version 1.17.0-date.20211022 go version: go1.17 Updates #81 Change-Id: Ic82ebffa5f46789089e5fb9810b3f29e36a47f1a Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Temporary measure until we switch to Go 1.18. $ go run ./cmd/tailscale version 1.17.0-date.20211022 go version: go1.17 Updates #81 Change-Id: Ic82ebffa5f46789089e5fb9810b3f29e36a47f1a Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Temporary measure until we switch to Go 1.18. $ go run ./cmd/tailscale version 1.17.0-date.20211022 go version: go1.17 Updates #81 Change-Id: Ic82ebffa5f46789089e5fb9810b3f29e36a47f1a Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Temporary measure until we switch to Go 1.18. $ go run ./cmd/tailscale version 1.17.0-date.20211022 go version: go1.17 Updates #81 Change-Id: Ic82ebffa5f46789089e5fb9810b3f29e36a47f1a Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Waiting on Go 1.18 in couple weeks. |
No more manual version bumps! Fixes #81 Change-Id: I3a9e544a7248f0b83bcbacbaabbc4dabc435e62d Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
No more manual version bumps! Fixes #81 Change-Id: I3a9e544a7248f0b83bcbacbaabbc4dabc435e62d Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
No more manual version bumps! Fixes #81 Change-Id: I3a9e544a7248f0b83bcbacbaabbc4dabc435e62d Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
No more manual version bumps! Fixes #81 Change-Id: I3a9e544a7248f0b83bcbacbaabbc4dabc435e62d Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
When we do tailscale binary releases, we stamp version info into the binaries with the Go linker.
But for people just using "go get" the default way, we don't have that info.
Since Go modules, we at least see the summary of all our deps (and Go's version itself; I'm running a devel build) automatically stamped into the binaries:
We can get that at runtime (using https://godoc.org/rsc.io/goversion/version) but for better or worse, that doesn't include that the Git hash of the top-level module, only the deps.
So one thing we could do is add a fake dep to another module (like github.com/tailscale/version-horizon) that we have a bot auto-advance every $INTERVAL, so at least we have a rough date range of what binary people are running when they're running unofficial binaries. Or, if we're already having a bot do this, avoid that indirection and just have the bot auto-commit the latest date to version/version.go every $INTERVAL instead.
Low priority, but we'll probably want better data in the future.
/cc @apenwarr @crawshaw @danderson
The text was updated successfully, but these errors were encountered: