Enable BSR push

[srikrsna-buf]

This enables pushing to the BSR. Managed modules only push releases. This will make it so that every commit is available on the BSR. This helps with developing/testing features as they are added to protovalidate between releases. For example, the protovalidate-go uses generated SDKs and without the intermediate commits on BSR, it is impossible to get the updated gen code.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Mar 19, 2026, 1:34 PM

[unmultimedio]

Tbh I'm not sure this will work, there is a check in the BSR backend that makes sure only the BSR syncer (and may be BSR admin, I will check) can push to modules marked as managed.

Could you do a test on an ephemeral BSR first? I'll ping you internally with details.

[unmultimedio]

This feature is allowed and enabled in the public MT BSR now, please retry.

One important note: this is allowed for all labels in both bufbuild/protovalidate and bufbuild/protovalidate-testing, even main (the default one). I'm not sure if you also wanna keep BSR's main aligned with Git's main, or if it should remain synced-only (which will continue happening).

I'd recommend to disable manual pushes to main in here, so main can be synced-only and remain the same across all BSR instances. cc @srikrsna-buf @timostamm @tdbuf @smallsamantha

[srikrsna-buf]

I'd recommend to disable manual pushes to main in here, so main can be synced-only and remain the same across all BSR instances.

We want main to match git, otherwise we can't depend on it in other implementations. The releases will be the same across BSR instances. If the content is the same the BSR doesn't create a new commit and just adds the labels, right?

[unmultimedio]

We want main to match git, otherwise we can't depend on it in other implementations.

Ok yes, in that case you'd want to keep main manually pushing to the BSR as well.

The releases will be the same across BSR instances.

Correct, if someone depends on <some_bsr_instance>/bufbuild/protovalidate:<some_semver_release> they'll get the same content back.

If the content is the same the BSR doesn't create a new commit and just adds the labels, right?

Correct, but if/when main differs from the latest published release, then the content from the public BSR diverge:

Some depending on	Will get
The public MT BSR buf.build/bufbuild/protovalidate(:main)	Whatever is on Git's main
A managed ST or on-prem BSR <some_bsr_instance>/bufbuild/protovalidate(:main)	Latest synced Semver release

But I think that's ok for your needs?

[srikrsna-buf]

But I think that's ok for your needs?

Yeah, we should be good. We can ask people to pin to a release version if depending on main is causing an issue.

[unmultimedio]

Before merging, you might wanna update the branch, so it retries again and this PR branch is pushed?

[srikrsna-buf]

Before merging, you might wanna update the branch, so it retries again and this PR branch is pushed?

https://buf.build/bufbuild/protovalidate/docs/sk/buf-push-ci

[timostamm]

I'm not sure if you also wanna keep BSR's main aligned with Git's main, or if it should remain synced-only (which will continue happening).

I do not think we can push commits to the BSR's main.

Let's say a new rule is added to validate.proto. Users are likely to end up with the new version - either they just got started with the most recent version, or they run buf dep update.

We have to expect that users start using the new rule, but protovalidate implementations will not validate the new rule as expected: Most will raise an error for the unknown rule, but some will not (a silent correctness bug).

Until we cut corresponding implementation releases, the only possible fix for the user is to pin to older version in buf.yaml. This problem already exists today, but only for the short window in time between protovalidate release and implementation releases. If we make this window bigger, the problem will become bigger.

[unmultimedio]

Let's say a new rule is added to validate.proto. Users are likely to end up with the new version - either they just got started with the most recent version, or they run buf dep update.

Good point. You could tweak this repo that if the Git's repo is main then push to label nightly (or similar) that you can use to test it on other implementations, that way main remain stable-semver-releases-only.

[unmultimedio]

That's fine, but don't you want to push Git's main to a non-default BSR label so you're able to test your other implementations?

[srikrsna-buf]

That's fine, but don't you want to push Git's main to a non-default BSR label so you're able to test your other implementations?

I'll do this in a separate PR.

[srikrsna-buf]

On every push in a PR the workflow was triggered twice. Once by the push event and also by the pull_request event. The way checkout worked in both the cases was different. While push did checkout a branch. The pull_request event checked out in detached head state. This resulted in the buf cli unable to determine the branch.

[unmultimedio]

cc @emcfarlane you're a bit more familiar with the Github action settings, do you see something in here that can be fixed in these settings?

[emcfarlane]

This goes into label behaviour. A github checkout is not the current commit, but the commit merged onto main. This is very useful for testing as it will capture any regressions that would otherwise be missed once merged into main. But this fails in buf because the we don't take a label argument but resolve it using the remote URL. This will always fail to resolve the detached state as this commit does not exist on the remote. So if you must push on the "pull_request" event we have to disable the git resolution feature of buf. I think there may also be other events that could be used.