Skip to content
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

ko version to report build/version information #21

Closed
imjasonh opened this issue Mar 27, 2019 · 8 comments
Closed

ko version to report build/version information #21

imjasonh opened this issue Mar 27, 2019 · 8 comments
Labels
good first issue Good for newcomers

Comments

@imjasonh
Copy link
Member

Using https://github.com/ahmetb/govvv

@imjasonh imjasonh added the good first issue Good for newcomers label Mar 27, 2019
@cezkuj
Copy link
Contributor

cezkuj commented Apr 14, 2019

I would like to take care of it. Could you advise on activities needed besides adding 'version' command? govvv changes build process (as you don't use go build directly anymore) and I don't see any build wrapper (Makefile/scripts etc.) to hide that. Same problem with using package, users 'go getting' ko wouldn't have it working.

@imjasonh
Copy link
Member Author

Thanks for your interest @cezkuj !

We don't currently have an official release process or any release scripts, which is probably a prerequisite for this.

For users can install via go get we can have go version return the commit hash that's checked out (by inspecting $GOPATH/src/github.com/google/ko/.git/refs/heads/master (or else whatever is HEAD) at runtime, if the const value isn't provided.

FWIW, I also found an alternative approach to govvv which is to use -ldflags to set the value of a package-level const at build-time.

@cezkuj
Copy link
Contributor

cezkuj commented Apr 15, 2019

As far as I see, govvv also uses -ldflags approach. I feel like that's most common way to get build info. Not sure if it is worth to have hard dependency on other project to reduce few less lines here and there - your call.
Shall I add Makefile/bash/bazel/anything else to wrap building and releasing process within that issue?
Or just add code for version command?

@imjasonh
Copy link
Member Author

Right you are. I don't have a strong opinion about taking a dependency on govvv, it seems pretty straightforward and if we ever needed to stop using it we could.

I think if you add a release script that populates consts which go version prints that'd be sufficient. We'll tag a release after that and document how to get an official release where go version prints something other than the commit hash.

@cezkuj
Copy link
Contributor

cezkuj commented Apr 15, 2019

Overall I agree, but one thing is a bit unclear to me, what do you mean by

populates consts which go version prints that'd be sufficient
go version prints something other than the commit hash.

I don't see any way to get it from go version, do you mean git rev-parse (or some equivalents)?
Would you like to also have version of go used for building in ko version output?

Edited for more clarity.

@imjasonh
Copy link
Member Author

Yeah, using git rev-parse would work, basically:

 // provided by govvv
var Version, BuildDate string

func goVersion() {
  if Version == "" {
    hash := gitRevParseHead() // output of `git rev-parse HEAD`
    fmt.Println("version (go get):, hash)
  } else {
    fmt.Println("version:", Version)
  }
}

Let me know if you had something else in mind. I don't have a strong opinion about what the output should look like. Users have only actually asked for a way to get the released version string from the command, we could skip the fallback for simplicity for now as well.

@cezkuj
Copy link
Contributor

cezkuj commented Apr 15, 2019

Ok, understood. Will prepare something like that + script to wrap releasing.
Thanks for answering!

imjasonh added a commit that referenced this issue May 17, 2019
Resolving #21 issue. Adding ko version and simple release script
@jonjohnsonjr
Copy link
Collaborator

Fixed by #25 and #81

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants