feat: add go_version_file support

[stevenh]

Add support for determining the version of buf to use from go.mod including full test for the functionality.

This allows go projects to have a single source for go module versions.

Also:

• Fixes from lint issues in README.md.

Fixes #155

[CLAassistant]

All committers have signed the CLA.

[stevenh]

Thanks for the PR. A few notes:

• We can't promise we will merge this, but will consider it as a feature. We don't recommend adding github.com/bufbuild/buf as a way to install the CLI - this installation method is not officially supported.
• I've added a few comments to start with some questions.
• If we do accept this as a feature, revert all changes not related to the feature (ie changes to makefile, eslint, readme lint, etc), so that the PR only relates to the feature.

Thanks for the review, wasn't expecting that as I left it in draft to finish off this morning ;-)

I've responded to all your notes with few questions and some clarification of the choices, looking forward to your feedback.

[stevenh]

@bufdev any feedback on this?

[bufdev]

Hey @stevenh - thanks for the PR, but we can't consider this at the moment. This isn't an officially supported installation path, and adding it as one isn't something we can budget for at this time unfortunately. We can revisit this in the future.

[stevenh]

Thanks for the feedback.

It's obviously a shame as it means people either have to not use your action or when incrementing buf versions have to change in multiple places.

In case you haven't seen it versioning tools using go.mod is one of the recommended practices details on the official go wiki in answer to How can I track tool dependencies for a module?.

[bufdev]

We've seen that, but we don't think it's a good practice, and isn't one we support - we've seen numerous issues with users installing tools in this manner with dependencies overlapping with their own code's dependencies, causing builds of the buf binary to use untested dependencies.

[danmrichards]

Hey @bufdev,

Could you elaborate on this point:

We don't recommend adding github.com/bufbuild/buf as a way to install the CLI - this installation method is not officially supported.

The installation docs do call out installation from source using go install as one of the primary install methods - https://buf.build/docs/installation

Agree with the take from @stevenh on this one. In a project where one is using the bufbuild GitHub actions alongside allowing folks to use buf locally, you can end up in a situation of maintaining the buf version in two different places. One in the GitHub action and another perhaps in a Makefile or shell script for local usage.

Another pattern we've used in the past to help with this is using GOBIN to set a local toolchain directory, avoiding the risk of overloading local versions of tools across many projects. Coupling that with being able to unify the version of buf from go.mod would make for quite a nice developer experience.

[emcfarlane]

The new buf-action supports versioning commands from the buf installed on the runner. This can be used to install the version in the go.mod file by calling the following:

go install github.com/bufbuild/buf/cmd/buf@$(go list -f '{{.Version}}' -m github.com/bufbuild/buf)

This removes the edge case of go.mod having a non-release but version. Closing for now, please raise an issue in buf-action if this doesn't solve your usecase.