GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — GitHub - bufbuild/modules: Collection of third-party modules managed and synced by Buf.

BranchesTags
Open more actions menu

Latest commit

 

History

1,189 Commits
1,189 Commits

Folders and files

NameName
Last commit message
Last commit date
.github
.github
 
 
cmd
cmd
 
 
internal
internal
 
 
modules
modules
 
 
private
private
 
 
proto
proto
 
 
scripts
scripts
 
 
.gitattributes
.gitattributes
 
 
.gitignore
.gitignore
 
 
.golangci.yaml
.golangci.yaml
 
 
LICENSE
LICENSE
 
 
Makefile
Makefile
 
 
README.md
README.md
 
 
buf.gen.yaml
buf.gen.yaml
 
 
buf.lock
buf.lock
 
 
buf.yaml
buf.yaml
 
 
go.mod
go.mod
 
 
go.sum
go.sum
 
 

Repository files navigation

modules

Description

This repository contains first and third-party modules synced and published to the Buf Schema Registry.

If you'd like a common third-party module to be managed by Buf, open an issue using the Managed Module Request for Buf Schema Registry issue template and our team will follow up.

Managed modules

We currently sync automatically the following modules:

Module Source Community Repository Depends on
bufbuild/confluent https://github.com/bufbuild/confluent-proto
bufbuild/protovalidate https://github.com/bufbuild/protovalidate
bufbuild/protovalidate-testing https://github.com/bufbuild/protovalidate - bufbuild/protovalidate
bufbuild/reflect https://github.com/bufbuild/reflect
cncf/xds https://github.com/cncf/xds - envoyproxy/protoc-gen-validate
- google/cel-spec
- googleapis/googleapis
envoyproxy/envoy https://github.com/envoyproxy/envoy - cncf/xds
- envoyproxy/protoc-gen-validate
- googleapis/googleapis
- opencensus/opencensus
- opentelemetry/opentelemetry
- prometheus/client-model
envoyproxy/protoc-gen-validate https://github.com/envoyproxy/protoc-gen-validate
envoyproxy/ratelimit https://github.com/envoyproxy/ratelimit - envoyproxy/envoy
gogo/protobuf https://github.com/gogo/protobuf
google/cel-spec https://github.com/google/cel-spec - googleapis/googleapis
googleapis/cloud-run https://github.com/googleapis/googleapis - googleapis/googleapis
googleapis/googleapis https://github.com/googleapis/googleapis
googlechrome/lighthouse https://github.com/GoogleChrome/lighthouse
googlecloudplatform/bq-schema-api https://github.com/GoogleCloudPlatform/protoc-gen-bq-schema
grpc/grpc https://github.com/grpc/grpc-proto - googleapis/googleapis
grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway
opencensus/opencensus https://github.com/census-instrumentation/opencensus-proto
opentelemetry/opentelemetry https://github.com/open-telemetry/opentelemetry-proto
prometheus/client-model https://github.com/prometheus/client_model
protocolbuffers/wellknowntypes https://github.com/protocolbuffers/protobuf

How we handle references

Each module is synced either from its source repository's releases or from its commits. Modules synced from releases get a reference for every release tag, even when the tagged contents are identical to the previous tag.

Modules synced from commits only get a reference when the commit changes the files we sync. We sync a curated subset of each source repository (see the rsync.incl file in the module's directory under modules/static), and in large repositories most commits leave that subset untouched. A reference for such a commit would point at contents that were already published under an earlier reference, so we skip it.

How we handle dependencies

Dependencies are an essential part of these community modules as they help developers reuse well known Protobuf types, reduce errors and speed up the development process. We do not control the source of these modules, and managing and pinning dependencies to their exact commit can be difficult, especially when multiple module sources and build systems are involved.

To minimize issues with pinned dependencies on these modules, we sync them in the following order. First, we sync standalone modules. After they succeed, we then sync the modules that depend on them, which use the latest pushed dependency commit. As long as the dependencies don’t have any breaking change in the source code, this should be sufficient and stable for upstream modules.

For special cases, we can pin a dependency in the static buf.yaml that we control, to force a managed module depend on a specific synced reference from another managed module. To know if a managed module has pinned dependencies for a specific reference, take a look at the buf.yaml in that reference's manifest in the sync directory.

Community

For help and discussion regarding Protobuf managed modules, join us on Slack.

For feature requests, bugs, or technical questions, email us at [email protected].

Legal

Offered under the Apache 2 license.

About

Collection of third-party modules managed and synced by Buf.

Topics

buf-clibuf-schema-registrygrpcprotobufprotocprotocol-buffers

Resources

Readme
Apache-2.0 license

Code of conduct

Code of conduct
Activity
Custom properties

Stars

37 stars

Watchers

4 watching

Forks

3 forks
Report repository

Releases

Used by

Contributors

Languages

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.