ci: Remove Buf tokens from workflow (celestiaorg#378)

* ci: Remove Buf tokens from workflow

Signed-off-by: Thane Thomson <[email protected]>

* Format proto folder readme to trigger workflow

Signed-off-by: Thane Thomson <[email protected]>

---------

Signed-off-by: Thane Thomson <[email protected]>

Author: thanethomson

.github/workflows/proto-lint.yml

@@ -16,10 +16,6 @@ jobs:
     steps:
       - uses: actions/checkout@v3
       - uses: bufbuild/buf-setup-action@v1.14.0
-        with:
-          github_token: ${{ secrets.BUF_GITHUB_API_TOKEN }}
-          buf_api_token: ${{ secrets.BUF_API_TOKEN }}
       - uses: bufbuild/buf-lint-action@v1
         with:
           input: 'proto'
-          buf_token: ${{ secrets.BUF_API_TOKEN }}

proto/README.md

@@ -1,23 +1,41 @@
 # Protocol Buffers
 
-This sections defines the types and messages shared across implementations. The definition of the data structures are located in the [core/data_structures](../spec/core/data_structures.md) for the core data types and ABCI definitions are located in the [ABCI](../spec/abci/README.md) section.
+This sections defines the types and messages shared across implementations. The
+definition of the data structures are located in the
+[core/data\_structures](../spec/core/data_structures.md) for the core data types
+and ABCI definitions are located in the [ABCI](../spec/abci/README.md) section.
 
 ## Process of Updates
 
-The `.proto` files within this section are core to the protocol and updates must be treated as such.
+The `.proto` files within this section are core to the protocol and updates must
+be treated as such.
 
 ### Steps
 
-1. Make an issue with the proposed change.
-   - Within in the issue members from both the CometBFT and Tendermint-rs team will leave comments. If there is not consensus on the change an [RFC](../docs/rfc/README.md) may be requested.
-  1a. Submission of an RFC as a pull request should be made to facilitate further discussion.
-  1b. Merge the RFC.
-2. Make the necessary changes to the `.proto` file(s), [core data structures](../spec/core/data_structures.md) and/or [ABCI protocol](../spec/abci).
-3. Open issues within CometBFT and Tendermint-rs repos. This is used to notify the teams that a change occurred in the spec.
-   1. Tag the issue with a spec version label. This will notify the team the changed has been made on master but has not entered a release.
+1. Make an issue with the proposed change.  Within in the issue members from
+   both the CometBFT and tendermint-rs team will leave comments. If there is not
+   consensus on the change an [RFC](../docs/rfc/README.md) may be requested.
+   1. Submission of an RFC as a pull request should be made to facilitate
+      further discussion.
+   2. Merge the RFC.
+2. Make the necessary changes to the `.proto` file(s), [core data
+   structures](../spec/core/data_structures.md) and/or [ABCI
+   protocol](../spec/abci).
+3. Open issues within CometBFT and Tendermint-rs repos. This is used to notify
+   the teams that a change occurred in the spec.
+   1. Tag the issue with a spec version label. This will notify the team the
+      changed has been made on master but has not entered a release.
 
 ### Versioning
 
-The spec repo aims to be versioned. Once it has been versioned, updates to the protobuf files will live on master. After a certain amount of time, decided on by CometBFT and tendermint-rs team leads, a release will be made on the spec repo. The spec may contain minor releases as well, depending on the implementation these changes may lead to a breaking change. If so, the implementation team should open an issue within the spec repo requiring a major release of the spec.
-
-If the steps above were followed each implementation should have issues tagged with a spec change label. Once all issues have been completed the team should signify their readiness for release.
+The spec repo aims to be versioned. Once it has been versioned, updates to the
+protobuf files will live on master. After a certain amount of time, decided on
+by CometBFT and tendermint-rs team leads, a release will be made on the spec
+repo. The spec may contain minor releases as well, depending on the
+implementation these changes may lead to a breaking change. If so, the
+implementation team should open an issue within the spec repo requiring a major
+release of the spec.
+
+If the steps above were followed each implementation should have issues tagged
+with a spec change label. Once all issues have been completed the team should
+signify their readiness for release.