You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 17, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 17, 2021. It is now read-only.
sshcode --version does not print version info #154
Yeah this is an issue with fetching sshcode using go get instead of downloading a release binary. Since we're not running ci/build.sh the version information is never set. Off the top of my head I don't think there's an easy way to make this fill in automatically when running go get and the obvious intention is to not have to update the version manually... I wonder if instead of printing an empty string it should just say something like unofficial?
The issue is that running go get -u go.coder.com/sshcode is leveraging the go tooling, it sees the presence of a main.go and compiles this to a binary. There's no way to make that tooling find the version and add it to the version string. The string value itself is set at compile-time using a ldflag which you otherwise don't get to pass in when running go get.
That's why it's blank currently, the string has no default value and nothing is being set using a ldflag. My suggestion above was to set a default value that would be overwritten by the script for official builds.
If you're installing from source there's no release version built into the binary. I don't think it's a big deal that it prints nothing in this case, but I'll accept a PR so custom builds say unofficial.
If you're installing from source there's no release version built into the binary. I don't think it's a big deal that it prints nothing in this case, but I'll accept a PR so custom builds say unofficial.
Yeah personally I'm totally indifferent my comments and suggestions here were just to other's benefit. That said if it's wanted by others I'll gladly submit such a PR, another option might be to simply link this issue from a FAQ in the readme, or yes leave it entirely as is as it's a pretty small non-annoyance 😄
One way to build with git versions is to use a script to sed a go file that
contained a variable?
Contents would be
package main
const version = "Version/commit string"
On Thu, Mar 12, 2020, 3:36 PM Nathan Bass ***@***.***> wrote:
If you're installing from source there's no release version built into the
binary. I don't think it's a big deal that it prints nothing in this case,
but I'll accept a PR so custom builds say unofficial.
Yeah personally I'm totally indifferent my comments and suggestions here
were just to other's benefit. That said if it's wanted by others I'll
gladly submit such a PR, another option might be to simply link this issue
from a FAQ in the readme, or yes leave it entirely as is as it's a pretty
small non-annoyance 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#154 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXTOOMUMBFKJBO2ZWCTRHFPVHANCNFSM4JR5QA3Q>
.
One way to build with git versions is to use a script to sed a go file that contained a variable? Contents would be package main const version = "Version/commit string"
The problem is that script will never be called by go get which is always going to be the preferred method for installing a go binary directly from source.
Ah, yeah, go really needs to get make file support, like just run `make go`
if go exists in the make file. And it would be steps done before "go build"
On Fri, Mar 13, 2020, 10:23 AM Nathan Bass ***@***.***> wrote:
One way to build with git versions is to use a script to sed a go file
that contained a variable? Contents would be package main const version =
"Version/commit string"
The problem is that script will *never* be called by go get which is
*always* going to be the preferred method for installing a go binary
directly from source.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#154 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXXEKIWXHZKJWDBU4BDRHJTZBANCNFSM4JR5QA3Q>
.
Activity
fonnesbeck commentedon Dec 19, 2019
Confirming this on Debian Linux, using sshcode built from source.
Merith-TK commentedon Dec 19, 2019
IngCr3at1on commentedon Dec 27, 2019
Yeah this is an issue with fetching sshcode using
go getinstead of downloading a release binary. Since we're not runningci/build.shthe version information is never set. Off the top of my head I don't think there's an easy way to make this fill in automatically when runninggo getand the obvious intention is to not have to update the version manually... I wonder if instead of printing an empty string it should just say something likeunofficial?Merith-TK commentedon Dec 27, 2019
Maybe git version?
IngCr3at1on commentedon Dec 27, 2019
How do you get the git version without a script? There's no way (to my knowledge) to get such a value using go get to build the binary.
Merith-TK commentedon Dec 27, 2019
uhm, check the git version of
GOPATH/src/github.com/cdr/sshcode?IngCr3at1on commentedon Dec 27, 2019
The issue is that running
go get -u go.coder.com/sshcodeis leveraging the go tooling, it sees the presence of a main.go and compiles this to a binary. There's no way to make that tooling find the version and add it to the version string. The string value itself is set at compile-time using a ldflag which you otherwise don't get to pass in when running go get.That's why it's blank currently, the string has no default value and nothing is being set using a ldflag. My suggestion above was to set a default value that would be overwritten by the script for official builds.
deansheather commentedon Feb 21, 2020
If you're installing from source there's no release version built into the binary. I don't think it's a big deal that it prints nothing in this case, but I'll accept a PR so custom builds say
unofficial.IngCr3at1on commentedon Mar 12, 2020
Yeah personally I'm totally indifferent my comments and suggestions here were just to other's benefit. That said if it's wanted by others I'll gladly submit such a PR, another option might be to simply link this issue from a FAQ in the readme, or yes leave it entirely as is as it's a pretty small non-annoyance 😄
Merith-TK commentedon Mar 13, 2020
IngCr3at1on commentedon Mar 13, 2020
The problem is that script will never be called by
go getwhich is always going to be the preferred method for installing a go binary directly from source.Merith-TK commentedon Mar 13, 2020