Shared generated Go packages, upstream where needed, first-party where it matters.

common-go

Generated Go packages for the shared Protocol Buffers contracts used across Alis Build, plus the upstream-generated packages those contracts import directly.

This repository is the Go module companion to common-protos. Where common-protos is the schema source of truth, common-go is the published Go distribution that consumers import from go.alis.build/common.

Go packages in the Define, Build & Deploy framework

Within the Alis Build platform, Protocol Buffers sit at the heart of the Define, Build & Deploy (DBD) framework. This repository exists one step downstream from that contract layer: it turns the shared protobuf definitions into importable Go packages that services, clients, and internal platform code can build against.

In Define, teams shape APIs and messages in common-protos.

In Build, this module provides the generated Go types, enums, service stubs, and supporting metadata needed to implement or consume those contracts without regenerating code in every repository.

In Deploy, shared generated packages help keep integrations predictable. Multiple services can compile against the same published module path and stay aligned on the same wire contract.

At a Glance

This module has three distinct namespace groups:

Namespace	Ownership	Purpose
alis/	Alis Build	First-party generated Go packages
google/	Google	Vendored generated packages for imported protos
lf/	Linux Foundation	Vendored generated Agent2Agent Go packages

The key distinction is that not every package in this repository is authored here. Some generated packages are published only because first-party Alis contracts import those upstream definitions and consumers benefit from one stable module path.

What Lives Here

First-party generated packages

These packages are generated from protobuf definitions owned by Alis Build and should evolve through the source protos in common-protos:

• alis/a2a/...
• alis/open/...
• common/...

Examples include packages such as:

• go.alis.build/common/alis/open/support/v1
• go.alis.build/common/alis/a2a/extension/history/v1
• go.alis.build/common/common/test/v1

Vendored upstream generated packages

These packages are generated from upstream protobuf definitions that our first-party APIs import directly:

• google/: common protobuf types, Google API annotations and service definitions, IAM, logging, RPC, long-running operations, and related support packages
• lf/: Linux Foundation Agent2Agent (A2A) protocol packages used as a baseline interoperability contract

Relationship to common-protos

Use the repositories for different purposes:

• update .proto files and contract design in common-protos
• consume generated Go packages from common-go

If a contract changes upstream, this repository should be regenerated and published so downstream Go consumers can pick up the new package version through the module path:

go.alis.build/common

Importing Packages

Import the generated package you need directly from this module:

import supportv1 "go.alis.build/common/alis/open/support/v1"

Because upstream dependencies are published under the same module, imports such as these also resolve from this repository:

import (
	iamv1 "go.alis.build/common/google/iam/v1"
	a2av1 "go.alis.build/common/lf/a2a/v1"
)

Contribution Rules

Treat this repository as generated output and published module surface area.

• Make contract changes in common-protos, not by hand-editing generated .pb.go files here.
• Regenerate first-party packages when alis/ or common/ protobuf sources change upstream.
• Treat google/ and lf/ as vendored upstream code unless there is a very deliberate reason to refresh or patch them.
• Keep package paths stable. Breaking API changes should be reflected in the protobuf package versioning strategy upstream.

Compatibility

For first-party packages published from this module:

• prefer additive changes
• avoid reusing protobuf field numbers
• version packages when making breaking changes
• document deprecations before removal

For vendored upstream packages:

• preserve upstream package names and import paths
• avoid unnecessary local divergence from the upstream source