Add configuration for goreleaser

[rogchap]

This adds basic configuration for goreleaser.
On a tagged release it will build for linux, osx and windows, and add to the GitHub release page, including the artifacts, changelog and checksum file.
To test locally you can run goreleaser --snapshot --skip-publish --rm-dist

I've also change the SemVer to be auto generated at build time via ldflags; This may cause slight confusion for people installing via go get as it will display 0.0.0-dev, but allows easier version management via CI releases (with goreleaser); In the future we should favour CI builds over using go get.

This is a prerequisite to having other distributions such as docker (#180) and homebrew (recommended)

I've amended CI (travis) to run the tests and do a deploy when there is a valid release tagged.

[rogchap]

Looks like there is a issue with the golden files and line endings on Windows \n vs \r\n 😞
Not sure the best way to fix? Maybe needs a build flag to select a different golden file based on platform?

Rather than fix this now, I'm going to remove windows from the test script. We can still build for Windows though.

[LandonTClipp]

Hi @rogchap , thanks a lot for the PR, this looks great. Unfortunately I think we really need to have the versioning saved into the go source code so that you can go get a specific version, as well as mockery being able to correctly identify its version when doing go get. The workflow I'd really like to have is this:

1. A human changes the SemVer variable in source, and commits to master.
2. Travis CI initiates build on master. Runs tests.
3. If tests are successful, Travis gets the SemVer using something like mockery -version
4. If the tagged version doesn't previously exist, tags the commit to master using the version from step 3, creates GH release and uploads necessary files.

The pattern of baking the version info on build time is a common one but one I'm not very fond of for Golang projects.

I don't think that should be too difficult to implement. What do you think?

[rogchap]

Hey @LandonTClipp,

I strongly recommend moving away from go get to install binaries. The Go Team have previously stated that this is a feature that they want to remove, but is only there for backward compatibility reasons.

go get results in inconsistent behavior depending on "gopath mode". If you use go get outside a Go modules repo this will install using "gopath mode" and would get, and install, the code in the master branch, which could have unreleased code. In "modules mode" this would install the latest git tagged version (unless the user does go get ...@v1.0.0). The version number installed is based off the git tag, not SemVer, so there is a possibility of version miss-matches.
Using a package manager for exec binaries are far easier to manage and maintain (homebrew etc); from both a user perspective and maintainer perspective.

goreleaser requires a git tag before it will build; so you always need a new valid git tag to do a deployment. The flow you describe is actually quite complex, because you would have to build the binary before building the binary (!!??) to get the version, check that there are no tags with that version and then (and only then) do a deployment based of that version. Not impossible, but quite messy, and unconventional from managing Go releases.

You could grep (or something like that) to get the version; but this would be brittle. You also need to remember to always bump the version number in a Go file and then update the test (I guess we could change the test to read SemVer?). This will get tedious if every patch you merge you manually have to update master with a new version, rather than just doing a git tag and it being automated.

If you are not keen on master containing version 0.0.0-dev maybe we could change this to master instead!?

If you really really really still want to maintain go get as a way to install, and really really really care that it does not output master (or 0.0.0-dev) when doing --version; Then we can change the default SemVer to be 1.0.0 (or whatever is latest) but still have the binary build process "override" the value from the git tag (we should change the test so that the golden generated file matches correctly).
This would result in two manual steps: update SemVer then git tag with same version. If you ever forgot to bump the SemVer at least the built binaries would have the correct version embedded from the git tag.

[LandonTClipp]

stretchr/testify still supports 1.11/1.12. Yes I know they're ancient but let's keep them in here for now.

https://github.com/stretchr/testify#supported-go-versions

[rogchap]

Surly this only effects the build of the mockery binary, rather than the supported Go output by the tool? We would only build mockery binary with the latest (1.14) so we could actually remove all but 1 Go version to run the tests. 💁‍♂️

That said, I've added both 1.11 and 1.12 back in as requested.

[LandonTClipp]

@rogchap thank you for all your input. After thinking it over I think what you are saying makes sense and we can go ahead and move forward. I really don't think that it's that complicated of a workflow but if that's how most of the Go community releases binaries I think we should follow that. Let's keep the idea of v0.0.0-dev but clearly mark how releases will be pushed in the README. Currently README says to go get stuff, an asterisk will need to be added to specify this is to get a development version. I can add this myself.

I will look this over once more on Monday and get this merged. I'll put in a few minor comments. Thanks!!

[mnaboka]

oops, this change has broken our CI, we are installing latest mockery and check for version to be 1.0.0 :(
this is the command we use to install mockery
GO111MODULE=off go get -u github.com/vektra/mockery/.../
any recommendation how to pin to a 1.0.0 release?
thanks 🙏

[LandonTClipp]

Okay, we might just need to change the default version to be 1.0.0 for backwards compatibility. I'll fix this. Regards,

…

-- Landon Clipp

On Sun, May 10, 2020, 2:09 PM Maksym Naboka ***@***.***> wrote: oops, this change has broken our CI, we are installing latest mockery and check for version to be 1.0.0 :( — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVWMAPZ5ZOHEZGNXB6M6NDRQ33XZANCNFSM4M3YQIQQ> .

[rogchap]

If you can run in modules mode, then go get github.com/vektra/mockery/.../@1.0.0 should work?
Otherwise I would change your CI to not check for 1.0.0, but rather 1.x

[LandonTClipp]

@mnaboka can you confirm your CI is fixed from the new commit? I think to prevent other CI's from breaking we need to add this back in. We should add a deprecation note for a few months to inform people the default SemVer is going to be v0.0.0-dev

[mnaboka]

@LandonTClipp sure, i've fixed it on my end, another issue is that all generated mocks also include a string with version, so all those mocks will also be changed.
Thank you

[LandonTClipp]

Yes the commit reverts back to the old behavior where SemVer is 1.0.0. Thank you for fixing it on your end. I've added a note in the README about this, we'll keep that deprecation for a while and then we can switch it back over to 0.0.0-dev after a few months. After that people will just need to fix their CI.