Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions .github/workflows/buf-push.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
name: Buf Push

# Publishes the OpenEngine schema module to the Buf Schema Registry
# (buf.build/ai-dynamo/openengine).
#
# This workflow is intentionally gated so it cannot auto-publish:
# * `workflow_dispatch` lets a maintainer trigger it by hand.
# * `push: tags: ['v*']` lets a tagged release publish a labeled commit.
# It does NOT run on every push to `main`.
#
# Prerequisites before this can succeed:
# 1. OSRB approval of BSR distribution for OpenEngine.
# 2. `buf.build/ai-dynamo` org + `openengine` module exist (public).
# 3. `BUF_TOKEN` repo secret is configured.
# Until then, the workflow is dormant.

on:
workflow_dispatch:
Comment on lines +17 to +18

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Restrict manual publishes to the release ref

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 👍 / 👎.

push:
tags:
- "v*"

permissions:
contents: read

# Serialize publishes: overlapping tag pushes (or a manual dispatch racing a
# tag push) must never run two `buf push` jobs against the single module at
# once. Never cancel an in-flight publish; queue the next run instead.
concurrency:
group: ${{ github.workflow }}
cancel-in-progress: false

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +29 to +31

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Use a real queue for serialized publishes

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 👍 / 👎.


jobs:
push:
runs-on: ubuntu-latest
if: github.repository == 'ai-dynamo/openengine'

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

steps:
- name: Check out repository
uses: actions/checkout@v4
Comment on lines +38 to +39

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 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.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

with:
version: "1.71.0"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

token: ${{ secrets.BUF_TOKEN }}
Comment on lines +42 to +45

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Pin the publishing action before passing the BSR token

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 👍 / 👎.

push: true
lint: false
format: false
breaking: false
archive: false
pr_comment: false
push_disable_create: true
1 change: 1 addition & 0 deletions buf.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@ version: v2

modules:
- path: proto
name: buf.build/ai-dynamo/openengine

lint:
use:
Expand Down
Loading