cweill / gotests

Automatically generate Go test boilerplate from your source code.
Apache License 2.0
4.92k stars 346 forks source link

Add version command #157

Closed teddylear closed 3 years ago

teddylear commented 3 years ago

Adding version command to show current version of gotests installed.

NOTE Had issue with tests failing intermittently locally (even on develop). Not sure what the issue, please let me know if this is a known issue or something I should make another ticket for. This only appears to be happening for the 1.16.x build.

133

coveralls commented 3 years ago

Coverage Status

Coverage remained the same at 95.619% when pulling d30b59faad4c6e3aa46978a409ecd9f84954f888 on teddylear:feature/add-version-command into 90387e1ec4df7885052899c78aea13cf842c0143 on cweill:develop.

butuzov commented 3 years ago

I wonder who is going to remember to bump the version manually? And Git commit? Maybe it's a nice time to add goreleaser to the project, and automate the build?

teddylear commented 3 years ago

@butuzov As they way things are now it would have to be a manual bump prior to release. Ideally there would be a way to automate this (I can look into goreleaser). Also let me know about git commit, I can try to add that as well.

butuzov commented 3 years ago

git commit is what @cweill was talking in https://github.com/cweill/gotests/issues/133#issuecomment-751405527

teddylear commented 3 years ago

@butuzov I have added code to add the commit on this branch, however the issue is that it requires the following build to inject the git commit hash.

export GIT_COMMIT=$(git rev-parse HEAD) && \
  go build -ldflags "-X github.com/cweill/gotests/gotests/process.GitCommit=$GIT_COMMIT"

As I'm new to golang, is there a way to set a default build script/build options when calling go build? I attempted searching for something like this but came up empty-handed. I'll keep looking but if you have any ideas of a better way to implement this/ build this let me know!

butuzov commented 3 years ago
  1. maybe it's worth moving out the version functionality from process.go. its quite short and independent to be passed down to the stream. maybe it's better to locate in some file let's call it version.go under gotests alongside main.go.
  2. injecting git commit: usually done with a Makefile, Taskfile, or something similar. One thing you don't need to forget that somebody can build an app without a build system in place (therefore your go code should work with from git build or go install). I have mention goreleaser above, it can be added to CI and run automatically once software tagged. Here is a small example of how goreleser config.

so work plan is next:

1) add version.go, and way to show version + including git hash it was built (testing it with manual builds). 2) test default case (devel) 3) add Makefile to automate git/version injecting 4) add CI step.

@cweill can maybe add anything he would like to see in the implementation of this feature, as an author and maintainer.

teddylear commented 3 years ago

@butuzov Ok I can look into this, but because go install needs to be supported then I cannot use the flags I mentioned? Else this will not work with go get correct?

butuzov commented 3 years ago

@butuzov Ok I can look into this, but because go install needs to be supported then I cannot use the flags I mentioned? Else this will not work with go get correct?

Good that you asked! I learned this recently and haven't tested it yet. Usually, version should support "devel builds", with a fallback to something like v0.0.0-devel (git commit if possible)

cweill commented 3 years ago

@teddylear Thanks for this PR. I agree with @butuzov, we should aim to automate the version number increasing. I'm not familiar with the best way to do this in Go, but there must be some precedence out there.

teddylear commented 3 years ago

Let me keep working on this, but I'll close this PR for now while implementing these changes.