feat: Official Buf Plugin

[Jake-RoundrockIO]

Per Buf's website:

Buf is building a modern Protobuf ecosystem

Our tools address many of the problems above, ultimately allowing you to redirect much of your time and energy from managing Protobuf files to implementing your core features and infrastructure.

The buf CLI

The buf CLI enables you to create consistent Protobuf APIs that preserve compatibility and comply with best practices. The tool is currently available on an open-source basis. The buf CLI incorporates these components to help you create consistent Protobuf APIs:

• A new developed high-performance Protobuf compiler.
• A linter that enforces good API design choices and structure.
• A breaking change detector that enforces compatibility at the source code or wire level.
• A generator that invokes your protoc plugins based on a configurable template.

The Buf Schema Registry (BSR)

The Buf Schema Registry (BSR) is a hosted SaaS platform that serves as your organization’s source of truth for your Protobuf APIs. The BSR enables you to centrally maintain compatibility and manage dependencies, while enabling your clients to consume APIs reliably and efficiently. Similar to npm for JavaScript, pip for Python, or cargo for Rust, the BSR finally brings dependency management to your Protobuf APIs.

The goal of this PR is to support further adoption of the Buf ecosystem of tooling by making this library available through the BSR Plugin system.

This will allow library users greater flexibility when utilizing ts-proto as it allows them:

1. The ability to generate code using the library without needing to install it from NPM, which may be useful depending on project workflow and at a bare minimum reduces node_module size.
2. To take advantage of the BSR Remote Generation feature. This feature creates NPM modules on the fly containing the code generated using ts-proto and a user's .proto files that can be used to standardize proto generation accross a project and/or team.

To meet this end, this PR introduces a new GitHub Actions workflow that, on tagged release, builds and pushes the latest version of ts-proto to the BSR Plugin registry.

In addition to the changes made in this PR, @stephenh it is necessary that you create an account with buf.build (I have checked and stephenh is available at the time of submission 😊) and perform the following steps.

1. Navigate to https://buf.build/settings/user and create an API Token.
2. Navigate to the Plugins tab of your account and click the Create Plugin button
   • Name the plugin ts-proto
   • Ensure it is Public
3. Create the secrets BUF_USERNAME and BUF_PASSWORD in this repository's settings tab and set them equal to your account name (presumably stephenh) and your API token, respectively.

With these steps completed, GitHub Actions should be able to automatically push to the BSR Plugin registry on tagged release.

Relates to issue #569

[stephenh]

Amazing set of instructions @Jake-RoundrockIO , thank you! Going to merge and see what happens!

[stephenh]

🎉 This PR is included in version 1.114.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Jake-RoundrockIO]

The tag triggered by the build.yml files does not appear to have triggered the buf.yml workflow

[Jake-RoundrockIO]

According to here it looks like it may be because I didn't use the ADMIN_TOKEN like you did in build.yml, which may allow the workflow to be triggered by the push resulting from the build.yml workflow.

@stephenh should I do another full PR or is that something you wish to edit on your end?

[stephenh]

Hey @Jake-RoundrockIO , I'm thinking it's because of this:

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

I.e. the way ts-proto is using semantic-release out-of-the-box, their scripts are creating a net-new commit with the changelog and tagging that one, but with a "skip ci" in it...

So, dunno, kinda looks like the Buf workflow will basically have to run on the pre-tagged commit, so on like pushes to main:

    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

...but then also either a) run as part of the existing main build to get the semantic-release determined version number, b) run in parallel to the main build and also invoke semantic-release but solely to determine the version number, c) ...something else?

[Jake-RoundrockIO]

I think option a should work fine as long as you can get the version number from sematic release. That's really the only thing it needs to know so that it can push that version tag to the registry.

[stephenh]

@Jake-RoundrockIO okay! It took a few tries but looks like it worked:

Thanks!

[Jake-RoundrockIO]

You're amazing! Thanks for the help getting this worked out!