Tags are not pushed to Buf schema registry

[hdevalence]

Describe the bug

Looking at https://buf.build/penumbra-zone/penumbra/tags/main, we just have a bunch of commit IDs and not any of our actual tagged versions.

I suspect this is because we're not pushing to buf on tags, only on deploys to main.

This is a problem because we would like API users to be able to pick a tagged version of the protobuf definitions to use against a tagged testnet.

[hdevalence]

We should be sure to fix this before the next testnet release.

[conorsch]

We suspect we just need to run the relevant github actions workflows on tag pushes. That should accommodate. I'll pick this one up.

[conorsch]

Looks like #1690 didn't resolve this; I still don't see any named tags on the buf build page. Re-opening to track follow-up.

[conorsch]

Looks like the buf-push action does not support pushing named git tags natively. In buf, a "tag" maps to the git commit sha1 by default. Now that buf supports multiple --tag options, we should be able to wire this up ourselves as manual workflow steps.

[hdevalence]

@conorsch Do we still want to do this?

[conorsch]

Yes, this would be hugely helpful for downstream implementers consuming the buf-built codegen: right now, the usual practice is "pull the latest" and try to time that action near release day. It'd be much saner if downstream could just say "I want v0.63.2" and pin that version explicitly. Looks like there's finally a pending PR to add this functionality to the GHA we use. I'll take a look and see if we can push tags from local CLI for a handful of our most recent tags.

[conorsch]

I just pushed a few historical tags by checking them out in git and using buf push --tag <tag>. It didn't like when I tried point releases, though:

❯ git checkout v0.63.0
Previous HEAD position was 7b99503f3 chore: release version 0.62.0
HEAD is now at cff167a33 chore: release version 0.63.0

❯ buf push --tag v0.63.0
2b51f85bc0ed40c99c3e453a744c6cad

❯ git checkout v0.63.1
Previous HEAD position was cff167a33 chore: release version 0.63.0
HEAD is now at d24587cf2 chore: release version 0.63.1

❯ buf push --tag v0.63.1
already_exists: new commit identical to latest on branch

❯ git checkout v0.63.2
Previous HEAD position was d24587cf2 chore: release version 0.63.1
HEAD is now at 231ed4dd3 chore: release version 0.63.2

❯ buf push --tag v0.63.2
already_exists: new commit identical to latest on branch

So only v0.63.0 is live: https://buf.build/penumbra-zone/penumbra/activity/commit/v0.63.0 On one hand, this behavior makes sense, because we didn't change the proto specs at all on the point releases. On the other, it's weird, because it suggests we'll need to suggest downstream implementers ignore point releases.

We'll see how the GHA PR review fares, and circle back. For now, I'll just push up a tag manually post-release to keep things organized, until we have a fully automated solution.

[conorsch]

Belatedly published a v0.64.0 BSR tag from v0.64.0 git tag. Will do the same for today's 65 release (#3554).

[conorsch]

❯ buf push --tag v0.65.0
already_exists: new commit identical to latest on branch

Well that's annoying: we haven't altered the protos from the latest push from main, so BSR is rejecting a new tag that would point to the same proto message. This is apparently expected behavior:

" A custom tag to push with each commit. The BSR does not currently support moving or duplicated tags, so use this with care."

Not sure there's much more we can do for devex here, but will make sure to ask some of our downstream integrators about reasonable expectations.