Add pre-commit globally (#393)

* Add pre-commit globally

* Fix CI errors

Author: ali-behjati

.github/workflows/pre-commit.yml

@@ -0,0 +1,19 @@
+name: Pre-commit checks
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  pre-commit:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-python@v2
+      - uses: actions-rs/toolchain@v1
+        with:
+          profile: minimal
+          toolchain: nightly
+          components: rustfmt, clippy
+      - uses: pre-commit/[email protected]

.github/workflows/pyth-cosmwasm-contract.yml

@@ -16,8 +16,8 @@ jobs:
       run:
         working-directory: ./cosmwasm/contracts/pyth
     steps:
-    - uses: actions/checkout@v2
-    - name: Build
-      run: cargo build --verbose
-    - name: Run tests
-      run: cargo test --verbose
+      - uses: actions/checkout@v2
+      - name: Build
+        run: cargo build --verbose
+      - name: Run tests
+        run: cargo test --verbose

.github/workflows/remote-executor.yml

@@ -2,10 +2,10 @@ name: Check Remote Executor
 
 on:
   pull_request:
-    paths: [ pythnet/remote-executor/** ]
+    paths: [pythnet/remote-executor/**]
   push:
     branches: [main]
-    paths: [ pythnet/remote-executor/** ]
+    paths: [pythnet/remote-executor/**]
 jobs:
   pre-commit:
     runs-on: ubuntu-latest
@@ -24,4 +24,3 @@ jobs:
           echo "/home/runner/.local/share/solana/install/active_release/bin" >> $GITHUB_PATH
       - name: Run executor tests
         run: cargo test-bpf --manifest-path ./pythnet/remote-executor/Cargo.toml
-        

.pre-commit-config.yaml

@@ -3,19 +3,36 @@ repos:
     rev: v3.2.0
     hooks:
       - id: trailing-whitespace
-        files: pythnet/
       - id: end-of-file-fixer
-        files: pythnet/
       - id: check-added-large-files
+  # Hook to format many type of files in the repo
+  # including solidity contracts.
+  - repo: https://github.com/pre-commit/mirrors-prettier
+    rev: "v2.7.1"
+    hooks:
+      - id: prettier
+        additional_dependencies:
+          - "[email protected]"
+          - "[email protected]"
   - repo: local
     hooks:
+      # Hooks for the remote executor
       - id: cargo-fmt-executor
         name: Cargo format executor
         language: "rust"
         entry: cargo +nightly fmt --manifest-path ./pythnet/remote-executor/Cargo.toml --all
         pass_filenames: false
+        files: pythnet/remote-executor/
       - id: cargo-clippy-executor
         name: Cargo clippy executor
         language: "rust"
         entry: cargo +nightly clippy --manifest-path ./pythnet/remote-executor/Cargo.toml -- -D warnings
         pass_filenames: false
+        files: pythnet/remote-executor/
+      # Hooks for the attester
+      - id: cargo-fmt-executor
+        name: Cargo format executor
+        language: "rust"
+        entry: cargo +nightly fmt --manifest-path ./solana/pyth2wormhole/Cargo.toml --all
+        pass_filenames: false
+        files: solana/pyth2wormhole/

CONTRIBUTING.md

@@ -10,18 +10,18 @@ and code reviews are our most important tools to accomplish that.
   complex features, it can be useful to submit a [formal design document](design/template.md).
 
 - Development happens on a long-lived development branch (`dev.v2` and `dev.v1`).
-  Every change going into a development branch is reviewed individually (see below). Release branches may be used 
+  Every change going into a development branch is reviewed individually (see below). Release branches may be used
   to support in-the-wild releases of Wormhole. We aim to support at most two release
   branches at the same time. Changes can be cherry-picked from the development branch to release branches, but
   never from release branches to a development branch.
-  
+
 - Releases are first tested on a testnet.
 
 - Commits should be small and have a meaningful commit message. One commit should, roughly, be "one idea" and
   be as atomic as possible. A feature can consist of many such commits.
-  
+
 - Feature flags and interface evolution are better than breaking changes and long-lived feature branches.
-  
+
 - We optimize for reading, not for writing - over its lifetime, code is read much more often than written.
   Small commits, meaningful commit messages and useful comments make it easier to review code and improve the
   quality of code review as well as review turnaround times. It's much easier to spot mistakes in small,
@@ -42,12 +42,12 @@ The answer is... maybe? The following things are needed in order to fully suppor
   a node or light client for every chain supported by Wormhole. This adds up, and the barrier to support new
   chains is pretty high. Your proposal should clearly outline the value proposition of supporting the new chain.
   **Convincing the DAO to run nodes for your chain is the first step in supporting a new chain.**
-  
+
 - The chain needs to support smart contracts capable of verifying 19 individual secp256k1 signatures.
 
 - The smart contract needs to be built and audited. In some cases, existing contracts can be used, like with
   EVM-compatible chains.
-  
+
 - Support for observing the chain needs to be added to guardiand.
 
 - Web wallet integration needs to be built to actually interact with Wormhole.

DEVELOP.md

@@ -7,7 +7,7 @@ The following dependencies are required for local development:
 - [Go](https://golang.org/dl/) >= 1.17.5
 - [Tilt](http://tilt.dev/) >= 0.20.8
 - Any of the local Kubernetes clusters supported by Tilt.
-  We strongly recommend [minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/) >= 
+  We strongly recommend [minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/) >=
   v1.21.0 with the kvm2 driver.
   - Tilt will use Minikube's embedded Docker server. If Minikube is not used, a local instance of
     [Docker](https://docs.docker.com/engine/install/) / moby-engine >= 19.03 is required.

Dockerfile.client

@@ -8,7 +8,7 @@ ARG WORMHOLE_TAG=v2.8.9
 RUN apt-get update && apt-get install -yq libudev-dev ncat
 RUN curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && apt-get install -y nodejs
 
-COPY solana /usr/src/solana 
+COPY solana /usr/src/solana
 WORKDIR /usr/src/solana/pyth2wormhole
 
 RUN --mount=type=cache,target=/root/.cache \

Dockerfile.cosmwasm

@@ -20,7 +20,7 @@ FROM cosmwasm/workspace-optimizer:0.12.6@sha256:e6565a5e87c830ef3e8775a9035006b3
 COPY cosmwasm/Cargo.lock /code/
 COPY cosmwasm/Cargo.toml /code/
 COPY cosmwasm/contracts /code/contracts
-COPY third_party/pyth/p2w-sdk/rust /third_party/pyth/p2w-sdk/rust 
+COPY third_party/pyth/p2w-sdk/rust /third_party/pyth/p2w-sdk/rust
 RUN --mount=type=cache,target=/code/target,id=cosmwasm_pyth_target --mount=type=cache,target=/usr/local/cargo/registry optimize_workspace.sh
 
 # Contract deployment stage

Dockerfile.solana

@@ -20,7 +20,7 @@ RUN sh -c "$(curl -sSfL https://release.solana.com/v1.10.31/install)"
 ENV PATH="/root/.local/share/solana/install/active_release/bin:$PATH"
 
 
-ADD solana/rust-toolchain /rust-toolchain
+ADD solana/pyth2wormhole/rust-toolchain /rust-toolchain
 # Solana does a questionable download at the beginning of a *first* build-bpf call. Trigger and layer-cache it explicitly.
 RUN cargo init --lib /tmp/decoy-crate && \
     cd /tmp/decoy-crate && cargo build-bpf && \

README.md

@@ -6,13 +6,13 @@ Pyth2Wormhole. The base repository is a fork from Certus One's reference
 for building projects based on Wormhole's various SDKs. Much of the existing
 documentation from there will also apply to this repository.
 
-[Wormhole]: https://github.com/wormhole-foundation/wormhole
+[wormhole]: https://github.com/wormhole-foundation/wormhole
 
 Within this monorepo you will find the following subprojects:
 
 ## Pyth2Wormhole Solana
->  solana/pyth2wormhole
 
+> solana/pyth2wormhole
 
 The main Pyth implementation currently exists as an [on-chain contract][] on
 Solana. In order to expose these prices cross-chain, the Pyth2Wormhole Solana
@@ -24,7 +24,8 @@ various P2W receiver contracts.
 [on-chain contract]: https://github.com/pyth-network/pyth-client
 
 ## Pyth2Wormhole Ethereum
->  ethereum/contracts/pyth
+
+> ethereum/contracts/pyth
 
 The Ethereum P2W contract acts as a receiver for Pyth prices relayed from the
 P2W Solana contract. It also provides a public API for other Ethereum contracts
@@ -35,7 +36,8 @@ examples.
 [pyth-evm-sdk]: https://github.com/pyth-network/pyth-sdk-solidity
 
 ## Pyth2Wormhole Price Service
->  third_party/pyth
+
+> third_party/pyth
 
 The P2W Price Service is an off-chain service which constantly observes the
 Wormhole network watching for price attestations emitted from the Pyth Solana
@@ -48,7 +50,7 @@ the [pyth-js][] repository.
 
 [pyth-js]: https://github.com/pyth-network/pyth-js
 
---------------------------------------------------------------------------------
+---
 
 See [DEVELOP.md](DEVELOP.md) for instructions on how to set up a local devnet, and
 [CONTRIBUTING.md](CONTRIBUTING.md) for instructions on how to contribute to this project.
@@ -60,3 +62,15 @@ implied. See the License for the specific language governing permissions and lim
 spoken - this is a very complex piece of software which targets a bleeding-edge, experimental smart contract runtime.
 Mistakes happen, and no matter how hard you try and whether you pay someone to audit it, it may eat your tokens, set
 your printer on fire or startle your cat. Cryptocurrencies are a high-risk investment, no matter how fancy.
+
+## Development
+
+### Releases
+
+We use [Semantic Versioning](https://semver.org/) for our releases.
+
+### pre-commit hooks
+
+pre-commit is a tool that checks and fixes simple issues (formatting, ...) before each commit. You can install it by following [their website](https://pre-commit.com/). In order to enable checks for this repo run `pre-commit install` from command-line in the root of this repo.
+
+The checks are also performed in the CI to ensure the code follows consistent formatting.