Documentation
¶
Overview ¶
Package toolpin answers one question for every forge surface that runs buf: which buf does THIS project pin?
buf had two pins in one project. forge pinned it (templates.BufVersion, what `forge ci gate` holds PATH to and the scaffolded ci.yml installs), and a project that needed another release kept its own copy of the decision — a Makefile BUF_VERSION smuggled into forge through $BUF and PATH (reliant: buf 1.57.0 against forge's 1.50.0). The two answers drifted, and which buf generated a file depended on whether forge or the Makefile started it.
Now the project's go.mod is the one place it is declared, exactly as it is for protoc-gen-go and protoc-gen-connect-go: a project that pins buf says so with a tool directive,
go get -tool github.com/bufbuild/buf/cmd/buf@v1.57.0
and every forge surface — `forge generate`, `forge ci gate` (verify-generated and buf-lint), `forge tools install buf`, `forge tools pins buf`, and the ci.yml forge scaffolds — runs that release. A project that declares none runs forge's pin. Dependabot moves the go.mod line like any other.
Index ¶
Constants ¶
const BufModule = "github.com/bufbuild/buf"
BufModule is buf's Go module; a go.mod that requires it (as a tool directive does) pins the buf the project runs.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Buf ¶
type Buf struct {
// Version is a Go module version, with its leading v ("v1.57.0").
Version string
Source Source
}
Buf is the buf a project runs.
func BufFor ¶
BufFor returns the buf projectDir pins: go.mod's BufModule when the module graph has it, forge's pin otherwise. projectDir "" (no project) is forge's pin. Memoised per directory for the life of the process.
Source Files