Skip to content

Publish the generator as a BSR remote plugin - #8

Merged
roderm merged 1 commit into
masterfrom
feat/buf-remote-plugin
Aug 30, 2026
Merged

roderm merged 1 commit into
masterfrom
feat/buf-remote-plugin

Conversation

@roderm

@roderm roderm commented Aug 30, 2026

Copy link
Copy Markdown
Collaborator

Consumers currently need protoc-gen-go-sqlmap on PATH. That is how svc/crm silently generated nothing for a while: a stale copy in a different bin directory shadowed the freshly installed one, and buf generate exited 0. A remote plugin removes the class of problem — buf runs the published image and buf.gen.yaml names a version:

plugins:
  - remote: buf.build/roderm/go-sqlmap:v0.1.0
    out: pkg/generated/
    opt: [paths=source_relative, plugins=schema+scanner+query]

What's here

buf.plugin.yaml — plugin metadata. Two dependency declarations matter:

  • deps: buf.build/protocolbuffers/go — the generated .sqlmap.go extends the message types that plugin emits, so it is only compilable alongside them.
  • registry.go.deps — pins github.com/roderm/protoc-gen-go-sqlmap, because the generated code imports pkg/query (Mask, Conn) and pkg/generated/schema/v1 (SchemaTable). Those are not optional extras; without them the output does not compile.

Dockerfile — what the BSR requires: linux/amd64, scratch base via multi-stage build, non-root user. Resulting image is 8MB.

Release workflow job — pushes on tag, but only after checking plugin_version and registry.go.deps match the tag. Since those pins reference the release, publishing them out of step would ship a plugin whose generated SDKs require a module version that does not exist. I verified the check fails on a drifted tag rather than only passing on a matching one.

Verification

Built the image and drove it through protoc as a real plugin, via a wrapper running docker run --rm -i. Output for testdata/subtype.proto is byte-identical to the golden file, so the containerised plugin behaves exactly like the local binary.

Notes for reviewers

  • This is a separate BSR resource from the existing buf.build/roderm/protoc-gen-go-sqlmap module, which carries the protos. Pushing this plugin does not publish the subtypes / subtype_of extensions — that still needs a module buf push, and remains what blocks svc/crm.
  • plugin_version is v0.1.0 while the latest tag is v0.0.2. I picked a minor bump given what has landed since; change it if you would rather it were v0.0.3.
  • min_version is "1.27", matching go.mod. That is a high floor for consumers of the generated SDKs — worth lowering if it excludes anyone, since nothing in the runtime packages obviously needs 1.27.
  • The push command is still buf beta registry plugin push; buf's docs say it will graduate to buf registry plugin push.
  • I have not pushed anything to the BSR — publishing needs your credentials and is yours to run.

🤖 Generated with Claude Code

Consumers currently need the binary on PATH, which is why svc/crm silently
generated nothing when a stale copy shadowed it. A remote plugin removes
that: buf runs the published image, and buf.gen.yaml names a version.

  plugins:
    - remote: buf.build/roderm/go-sqlmap:v0.1.0

buf.plugin.yaml carries the metadata, including the runtime module the
generated code imports -- pkg/query and pkg/generated/schema/v1 are not
optional for compiling the output, so registry.go.deps pins them. It also
declares protocolbuffers/go as a dependency, since .sqlmap.go extends the
message types that plugin emits.

Because those pins reference the release, plugin_version and
registry.go.deps have to match the git tag. The release workflow checks
that before pushing rather than shipping a plugin whose generated SDKs
require a module version that does not exist yet.

The Dockerfile follows what the BSR requires: linux/amd64, a scratch base
via a multi-stage build, and a non-root user. The resulting image is 8MB.

Verified by building the image and driving it through protoc as a real
plugin: the output for testdata/subtype.proto is byte-identical to the
golden file.

Note the plugin is a separate BSR resource from the existing
buf.build/roderm/protoc-gen-go-sqlmap *module*, which carries the protos;
pushing this does not publish the sqlmap extensions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@roderm
roderm merged commit a27ee58 into master Aug 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant