feat(bsr): scaffold Buf Schema Registry publishing (module name + gated push CI)#26
Conversation
…ed push CI)
Add the BSR module name (buf.build/ai-dynamo/openengine) to buf.yaml and
introduce a gated .github/workflows/buf-push.yml that runs bufbuild/buf-action@v1
with push: true. The workflow only fires on workflow_dispatch or version tags
(v*), and only on the ai-dynamo/openengine repository, so nothing publishes
until a maintainer opts in.
This is scaffolding only. It does not publish yet:
* OSRB approval of the BSR distribution is pending (scope-extension comment
on NVBug 6405069).
* The buf.build/ai-dynamo org and openengine module do not exist yet.
* BUF_TOKEN is not configured in the repository secrets.
* push_disable_create: true blocks accidental module auto-creation.
No SDK generation is added (module-only per the OSRB request).
Signed-off-by: Dan Gil <dagil@nvidia.com>
Add a workflow-level concurrency guard to buf-push.yml so overlapping version-tag pushes (or a manual dispatch racing a tag push) cannot run two `buf push` jobs against the single BSR module at once. Uses cancel-in-progress: false so an in-flight publish is never cancelled; the next run queues behind it instead. Scaffolding hardening only. The workflow remains dormant (still gated on OSRB approval, org/module creation, and BUF_TOKEN). Signed-off-by: Dan Gil <dagil@nvidia.com>
connorcarpenter15
left a comment
connorcarpenter15
left a comment
There was a problem hiding this comment.
Thanks @dagil-nvidia
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| - name: Check out repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔍 Shallow checkout may weaken buf push git metadata/labeling
The new push job uses actions/checkout@v4 with default settings (.github/workflows/buf-push.yml:39), which performs a shallow clone (fetch-depth: 1). bufbuild/buf-action with push: true typically attaches git metadata and creates a label from the commit history when publishing to the BSR. With only the tip commit available, the labeled/commit information pushed to the registry may be incomplete compared to a full-history checkout (fetch-depth: 0). This is not a functional failure and matches the pattern in the existing buf.yml lint workflow, but is worth verifying against buf-action's push documentation before relying on rich commit labeling in the registry.
Was this helpful? React with 👍 or 👎 to provide feedback.
@alec-flowers @connorcarpenter15 I'll put in a fix for this |
alec-flowers
left a comment
alec-flowers
left a comment
There was a problem hiding this comment.
Follow-up review after merge: Buf CLI v1.72.0 was published as a stable release on July 17, so the 1.71.0 pins are already one version behind. I also found several publishing-safety issues below. I recommend addressing these in a follow-up PR before enabling BUF_TOKEN or performing the first BSR publish.
| jobs: | ||
| push: | ||
| runs-on: ubuntu-latest | ||
| if: github.repository == 'ai-dynamo/openengine' |
There was a problem hiding this comment.
Publishing is gated only by repository identity. workflow_dispatch can target an arbitrary branch, and a v* tag can point at any commit; there is currently no applicable tag-target ruleset. Since lint, format, and breaking checks are disabled below, a repository writer can publish unreviewed schema to the public BSR. Please restrict manual dispatches to main and protect/approve release tags (or use an approval-protected environment), and run at least lint in the publishing job.
| # once. Never cancel an in-flight publish; queue the next run instead. | ||
| concurrency: | ||
| group: ${{ github.workflow }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
cancel-in-progress: false protects the running publish, but GitHub's default concurrency queue retains only one pending run. If a third tag/manual publish arrives, it cancels the older pending publish, potentially leaving a Git release tag without its BSR label. Add queue: max to make the serialization match the comment above.
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Push schema to Buf Schema Registry | ||
| uses: bufbuild/buf-action@v1 |
There was a problem hiding this comment.
version pins only the downloaded Buf CLI; bufbuild/buf-action@v1 is a movable action tag and this step receives the privileged BUF_TOKEN. Pin the action to the full v1.4.0 commit SHA: bufbuild/buf-action@fd21066df7214747548607aaa45548ba2b9bc1ff # v1.4.0.
| if: github.repository == 'ai-dynamo/openengine' | ||
| steps: | ||
| - name: Check out repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
A default depth-1 tag checkout normally exposes the release tag but not the main branch. Because Buf's --git-metadata derives BSR labels from refs present at the checked-out commit, tag-only publishing can advance vX.Y.Z while leaving the BSR default main label empty or stale. Please define and verify the intended stable/default-label strategy before the first publish.
| - name: Push schema to Buf Schema Registry | ||
| uses: bufbuild/buf-action@v1 | ||
| with: | ||
| version: "1.71.0" |
There was a problem hiding this comment.
This is no longer the latest stable Buf CLI. v1.72.0 was published on July 17, 2026. Please update this pin—and the existing .github/workflows/buf.yml pin—to "1.72.0" together so the lint and publish workflows remain consistent.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e5d22ac78
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| concurrency: | ||
| group: ${{ github.workflow }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
For bursts of more than two publishes, this single concurrency group does not actually queue every run: GitHub's concurrency docs state that with the default queue behavior, "any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place." A manual dispatch racing two v* tag pushes can therefore drop one pending publish, leaving that tag absent from the BSR even though the comment says the next run is queued; use an explicit multi-run queue or another serialization strategy if every release tag must be published.
Useful? React with 👍 / 👎.
| uses: bufbuild/buf-action@v1 | ||
| with: | ||
| version: "1.71.0" | ||
| token: ${{ secrets.BUF_TOKEN }} |
There was a problem hiding this comment.
This new publishing workflow gives bufbuild/buf-action@v1 the BUF_TOKEN, but the action is pinned only to the mutable v1 tag. If that tag is moved or the upstream action is compromised, the replacement code runs with registry push credentials and can publish or exfiltrate the token; pin this third-party action to a full commit SHA for the secret-bearing publish job.
Useful? React with 👍 / 👎.
| on: | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Because workflow_dispatch is enabled without any ref guard, a manual run can publish whatever branch the dispatcher selects; GitHub's manual-run docs explicitly include a Branch dropdown and gh workflow run --ref for non-default branches. In this workflow actions/checkout then checks out that selected ref and the next step pushes it to BSR, so a maintainer can accidentally publish unmerged or experimental schema from a feature branch; add a github.ref check or environment gate so manual publishes only run from the intended release branch/ref.
Useful? React with 👍 / 👎.
3 participants
Summary
Scaffolds publishing the OpenEngine protobuf module to the Buf Schema Registry at
buf.build/ai-dynamo/openengine. This is a module-only setup. It does not add SDK generation and does not publish anything on its own.Two changes:
buf.yaml— add the BSR module name to the existing v2 module entry (name: buf.build/ai-dynamo/openengine). Lint config is unchanged..github/workflows/buf-push.yml— new gated workflow that runsbufbuild/buf-action@v1(pinned to1.71.0) withpush: trueandtoken: ${{ secrets.BUF_TOKEN }}. Gated three ways:workflow_dispatchand version tags (v*). No push-to-main auto-publish.if: github.repository == 'ai-dynamo/openengine'so forks and mirrors are inert.push_disable_create: trueblocks accidental BSR module auto-creation.The existing
.github/workflows/buf.ymllint workflow is unchanged.Prerequisites before this can merge and publish
buf.build/ai-dynamoorg andopenenginemodule, both public.BUF_TOKENrepository secret configured with a BSR token that has push rights on the module.Once those three are in place, a maintainer can either run the workflow from the Actions tab or cut a
v*tag to publish a labeled commit to the registry.Test plan
Buflint workflow passes on this PR (validates the newname:field against the existing STANDARD lint config).workflow_dispatchrun ofBuf Pushsucceeds against a realBUF_TOKEN.v*tag pushes a labeled commit tobuf.build/ai-dynamo/openengine.