Include prebuilt executables in releases

[andrew-womeldorf]

Is your feature request related to a problem? Please describe.
In order to buf generate, my environment must have go installed so that I can first install protoc-gen-connect-go.

Describe the solution you'd like
Include prebuilt executables with releases.

Describe alternatives you've considered
Install go and use go install... 😄

Additional context
This is certainly a convenience request. My current situation is trying to create more efficient CI jobs. I can download protoc-gen-go and buf without needing to bloat the build environment by installing go and associated tools. It would be nice to be able to simply download an executable for protoc-gen-connect-go as well.

[emcfarlane]

It's usually assumed to use and build the libraries go would be required locally. Install can be done with:

go install connectrpc.com/connect/cmd/protoc-gen-connect-go@latest

As an alternative you can use remote code generation using buf. This doesn't require you to manage the plugin binaries locally. See the docs here for more details: https://buf.build/docs/bsr/remote-plugins/usage#4.4.-connect-go

Release binaries would be a nice addition though. I'll let others weigh in but I agree with this proposal.

[akshayjshah]

I agree that release binaries would be nice, even if they're unnecessary for people using the buf CLI. @emcfarlane Can we look into integrating GoReleaser in this repo?

[andrew-womeldorf]

As an alternative you can use remote code generation using buf. This doesn't require you to manage the plugin binaries locally. See the docs here for more details: https://buf.build/docs/bsr/remote-plugins/usage#4.4.-connect-go

Oh, awesome. This worked great. I didn't realize that I could do this. Thank you!

[moko-poi]

Hi! @emcfarlane @akshayjshah
I'm interested in helping with this enhancement.
I noticed PR #696 was attempted but closed with "needs to be reworked." Could you provide guidance on what went wrong and whether this is still wanted?
If GoReleaser integration is what's needed here, I'm willing to take on that implementation.

[jhump]

@moko-poi, there were a few ways we needed to improve on that. I thought I had commented on Ed's PR, but I see there are no comments or threads in there.

The main changes needed:

1. Most important IMO is to actually automate and document the release process. I think we'd want configuration more-or-less identical to how releases of the conformance suite work.
2. We also should be verifying the release in CI with every commit. That way, we'll catch any issues that cause the release process to fail before we're actually trying to cut a release. That can be done with an extra "checkrelease" target (like this one) in the Makefile that gets run during the normal CI workflow.

[moko-poi]

@jhump Thank you for the detailed explanation!

I completely agree with your approach. You're absolutely right that automating and documenting the release process is the most critical part - without proper automation, maintaining prebuilt binaries across multiple platforms would become a maintenance burden.

The conformance suite implementation you referenced provides an excellent blueprint. I can see how the combination of GoReleaser configuration, the checkrelease Makefile target, and CI integration creates a robust and reliable release pipeline.

I'd like to create a PR that implements:

1. GoReleaser configuration (.goreleaser.yml) for multi-platform binary builds
2. checkrelease target in the Makefile for snapshot builds and validation
3. CI integration to run make checkrelease on every commit
4. GitHub Actions workflow for automated releases when tags are created

I'll model this closely after the conformance suite setup, adapting it for protoc-gen-connect-go. Should I also include a RELEASE.md documentation file as part of this initial implementation, or would you prefer to handle the documentation separately?

Let me know if this approach sounds good, and I'll get started on the implementation.

[jhump]

Should I also include a RELEASE.md documentation file as part of this initial implementation

It looks like the existing RELEASE.md process will still apply in its entirety. We could add a single bullet about checking the "release" GitHub action after publishing the release (to make sure it successfully produces the binaries and attaches them to the release). But it otherwise does not need changes, so I wouldn't worry about it.