diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 952d709..74a14fc 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -41,7 +41,7 @@ jobs: run: gh release create "$GITHUB_REF_NAME" --title "Release $GITHUB_REF_NAME" --generate-notes env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - # The BSR remote plugin, so consumers can use `remote: buf.build/roderm/ + # The BSR remote plugin, so consumers can use `remote: buf.build/snaerverk/ # go-sqlmap` instead of installing the binary. Runs after `release` because # buf.plugin.yaml's license_url points at the tag's LICENSE. plugin: diff --git a/CLAUDE.md b/CLAUDE.md index a0de45b..4cae2df 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,22 +6,22 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co `protoc-gen-go-sqlmap` is a `protoc`/`buf` code-generator plugin. Given `.proto` messages annotated with `sqlmap` extensions (table/column metadata, primary keys, foreign keys), it emits a `.sqlmap.go` per proto file containing `schema.v1.SchemaTable`/`SchemaColumn` values plus row-scanning helpers. `pkg/migration` then converts those values into `ariga/atlas` schema types to create tables or write migration files. -The goal is a set of independently switchable plugins over one shared `TableRepo`: (1) atlas migrations — **done**; (2) queries with eager loading of children + FieldMask support — **done**; (3) SQL filters built from the filtrify AST (`github.com/roderm/filtrify`, `proto/filtrify/ast/v1/ast.proto`). Note `docs/plans/sqlmap-generator/PLAN-SQLMAP-GENERATOR.md` is stale on (3): its Phase 5 sketches ad-hoc per-column builder funcs rather than translating an external AST. +The goal is a set of independently switchable plugins over one shared `TableRepo`: (1) atlas migrations — **done**; (2) queries with eager loading of children + FieldMask support — **done**; (3) SQL filters built from the filtrify AST (`github.com/snaerverk/filtrify`, `proto/filtrify/ast/v1/ast.proto`). Note `docs/plans/sqlmap-generator/PLAN-SQLMAP-GENERATOR.md` is stale on (3): its Phase 5 sketches ad-hoc per-column builder funcs rather than translating an external AST. Plugins are toggled with the `plugins=` protoc parameter, a **`+`-separated** list (protoc already uses `,` between parameters): `--go-sqlmap_out=plugins=schema+scanner:.`. Omitting it enables everything. `plugins` entries live in one slice in `generator.go`; `query` declares `Requires: ["scanner"]` because its output calls the scanner's `Result` type, and enabling it alone is a generation-time error rather than uncompilable Go. ### BSR remote plugin -`buf.plugin.yaml` + `Dockerfile` publish the generator as `buf.build/roderm/go-sqlmap`, so consumers need no local binary: +`buf.plugin.yaml` + `Dockerfile` publish the generator as `buf.build/snaerverk/go-sqlmap`, so consumers need no local binary: ```yaml plugins: - - remote: buf.build/roderm/go-sqlmap:v0.1.0 + - remote: buf.build/snaerverk/go-sqlmap:v0.1.0 out: pkg/generated/ opt: [paths=source_relative, plugins=schema+scanner+query] ``` -`buf.plugin.yaml` pins the runtime module the generated code imports (`pkg/query`, `pkg/generated/schema/v1`), so `plugin_version` and `registry.go.deps` must both match the git tag — the release workflow fails if they drift. Publishing happens in CI on tag (`buf beta registry plugin push`, needs `BUF_TOKEN`); it is a separate resource from the `buf.build/roderm/protoc-gen-go-sqlmap` *module* that carries the protos. Test the image locally with `docker build -t x . && protoc --plugin=protoc-gen-y=