Test Dockerfile Action

CONTRIBUTING.md

@@ -0,0 +1,159 @@
+# Contributing
+
+Wormhole is an open-source project licensed under the permissive Apache 2 license. Contributions are greatly
+appreciated and will be reviewed swiftly.
+
+Wormhole is a mission-critical, high-stakes project. We optimize for quality over quantity. Design processes
+and code reviews are our most important tools to accomplish that.
+
+- All new features must first be discussed in a GitHub issue before starting to implement them. For
+  complex features, it can be useful to submit a [formal design document](design/template.md).
+
+- Development happens on a long-lived development branch (usually `main` or `dev.<x>` for larger changes).
+  Every change going into a development branch is reviewed individually (see below). Release branches branched
+  from `main` are 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. This involves coordination with the mainnet DAO running the nodes.
+
+- 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,
+  well-defined changes.
+
+Documentation for the in-the-wild deployments lives in the
+[wormhole-networks](https://github.com/certusone/wormhole-networks) repository.
+
+## Contributions FAQ
+
+### Can you add \<random blockchain\>?
+
+The answer is... maybe? The following things are needed in order to fully support a chain in Wormhole:
+
+- The Wormhole mainnet is governed by a DAO. Wormhole's design is symmetric - every guardian node needs to run
+  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.
+
+The hard parts are (1) convincing the DAO to run the nodes, and (2) convincing the core development team to
+either build the integration, or work with an external team to build it.
+
+Please do not open a GitHub issue about new networks - this repository is only a reference implementation for
+Wormhole, just like go-ethereum is a reference implementation for Ethereum. Instead, reach out to the
+[Wormhole Network](https://wormholenetwork.com).
+
+### Do you support \<random blockchain innovation\>?
+
+Probably :-). At its core, Wormhole is a generic attestation mechanism and is not tied to any particular kind
+of communication (like transfers). It is likely that you can use the existing Wormhole contracts to build your
+own features on top of, without requiring any changes in Wormhole itself.
+
+Please open a GitHub issue outlining your use case, and we can help you build it!
+
+## Submit change for review
+
+Certus One uses **Gerrit** for code review on [**forge.certus.one**](https://forge.certus.one). Gerrit has the
+advantage of dealing with a stack of individual commits, rather than reviewing an entire branch. This makes it
+much easier to review large features by breaking them down into smaller pieces, and puts a large emphasis on
+clean commits with meaningful commit messages. This workflow helps us write better software.
+
+We do not currently accept GitHub pull requests.
+
+The GitHub repository is a mirror of the Gerrit repository. GitHub has a global CDN for Git, so if you plan
+to clone the Wormhole repo a lot in an automated fashion, please clone it from GitHub.
+
+### Why Gerrit?
+
+With GitHub, if you want to submit three changes A, B and C to be reviewed (in that order), you have two
+choices:
+
+- Submit a single PR with carefully rebased commits, and ask the reviewer to actually look at your
+  carefully-written commit messages and review each commit individually. However, this is not well-supported
+  by the UI, approval can only be given for the whole stack, and rebasing/adding commits breaks it altogether.
+  It also doesn't work with the squash merge policy used by many projects.
+
+- Submit three individual PRs with different bases. This allows you to approve and merge each change
+  individually, but requires you to manually rebase multiple branches on top of each other, which is annoying.
+
+By making it hard to break changes up into smaller pieces, GitHub encourages large, hard-to-review changes.
+With Gerrit, the opposite is true - it's **trivial to submit a stack of changes**. You can just put your
+changes A, B and C on a single branch:
+
+    C  <-- HEAD
+    ↑
+    B
+    ↑
+    A
+    ↑
+    O <-- origin/main, main
+    ↑
+    …
+
+... and submit all three using a single `git push origin HEAD:refs/for/main`. Gerrit will create a review
+request for A, B and C, and it understands the relation chain between them. C can only be merged after B and
+C, and merging C will automatically merge B and C as well.
+
+This means that A can be reviewed, approved and merged before B and C are done. Other team members can then
+start building on A and avoid a "big scary merge". This workflow is often called **trunk-based development**.
+
+Other advantages of Gerrit include:
+
+- The ability to **compare different versions of a change**, with inline comments shown in their original place.
+  This is very useful when re-reviewing a change.
+- Keeping inline comments across rebases (!).
+- Very responsive user interface that can be fully driven using keyboard shortcuts.
+  GitHub can be slow - opening a PR and showing the diff often takes multiple seconds.
+- A view that shows an overview of open comments, their status and a small code snippet.
+- Comments can be attached to a selection, not just entire lines. 
+  Multiple threads can be attached to the same line.
+- The "**attention set**" mechanism with a fine-grained state machine on who needs to take action,
+  which avoids sending non-actionable email notifications!
+- We run our own infrastructure. Yay decentralization!
+
+### Quickstart
+
+You can log into Gerrit using your Google account. **If you're contributing on behalf of a company, make
+sure that your Git email address reflects your affiliation!**
+
+First, add your SSH keys to Gerrit in your [profile settings](https://forge.certus.one/settings/#SSHKeys).
+Alternatively, you can generate an HTTP Password and store it in your [Git credentials store of
+choice](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage) - this is particularly useful for
+development hosts or corporate environments that can't use SSH or access your key.
+
+**Clone the repo from Gerrit** if you haven't done so already by going to the [repository
+page](https://forge.certus.one/admin/repos/wormhole) and using the *"Clone with commit-msg hook"* command. If
+you have an existing GitHub checkout you want to convert, you can simply set a new remote and you'll be
+prompted to install the hook the first time you push to Gerrit:
+
+    git remote set-url origin ssh://<gerrit-username>@[...]
+
+Then, just commit to a local branch. Every local commit becomes one code review request. Multiple commits on
+the same branch will be submitted as a stack (see above). Once you're done, push to the special ref that
+creates your code reviews:
+
+    git push origin HEAD:refs/for/main
+
+(replace `main` by a different development branch, where applicable)
+
+That's it! No special tooling needed. You can now go look at your commits in the web UI and add reviewers. If
+you want less typing, take a look at these:
+
+- There's an excellent [IntelliJ plugin](https://plugins.jetbrains.com/plugin/7272-gerrit) that allows you to clone,
+  check out and even review CLs from inside your IDE.
+
+- The Go project's [git-codereview](https://pkg.go.dev/golang.org/x/review/git-codereview) CLI utility.

DEVELOP.md

@@ -0,0 +1,99 @@
+# Developing the bridge
+
+## Local Devnet
+
+The following dependencies are required for local development:
+
+- [Go](https://golang.org/dl/) >= 1.17.0
+- [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/) >= 
+  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.
+
+See the [Tilt docs](https://docs.tilt.dev/install.html) docs on how to set up your local cluster -
+it won't take more than a few minutes to set up! Example minikube invocation, adjust limits as needed:
+
+    minikube start --cpus=8 --memory=8G --disk-size=50G --driver=kvm2
+
+npm wants to set up an insane number of inotify watches in the web container which may exceed kernel limits.
+The minikube default is too low, adjust it like this:
+
+    minikube ssh 'echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p'
+
+This should work on Linux, MacOS and Windows.
+
+By default, the devnet is deployed to the `wormhole` namespace rather than `default`. This makes it easy to clean up the
+entire deployment by simply removing the namespace, which isn't possible with `default`. Change your default namespace
+to avoid having to specify `-n wormhole` for all commands:
+
+    kubectl config set-context --current --namespace=wormhole
+
+After installing all dependencies, just run `tilt up`.
+Whenever you modify a file, the devnet is automatically rebuilt and a rolling update is done.
+
+Launch the devnet while specifying the number of guardians nodes to run (default is five):
+
+    tilt up -- --num=1
+
+If you want to work on non-consensus parts of the code, running with a single guardian is easiest since
+you won't have to wait for k8s to restart all pods.
+
+## Usage
+
+Watch pod status in your cluster:
+
+    kubectl get pod -A -w
+
+Get logs for single guardian node:
+
+    kubectl logs guardian-0
+
+Restart a specific pod:
+
+    kubectl delete pod guardian-0
+
+Adjust number of nodes in running cluster: (this is only useful if you want to test scenarios where the number
+of nodes diverges from the guardian set - otherwise, `tilt down --delete-namespaces` and restart the cluster)
+
+    tilt args -- --num=2
+
+Tear down cluster:
+
+    tilt down --delete-namespaces
+
+Once you're done, press Ctrl-C. Run `tilt down` to tear down the devnet.
+
+
+### Post messages
+
+To Solana:
+
+    kubectl exec solana-devnet-0 -c setup -- client post-message Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o 1 confirmed ffff
+
+To Solana as CPI instruction:
+
+    kubectl exec solana-devnet-0 -c setup -- client post-message --proxy CP1co2QMMoDPbsmV7PGcUTLFwyhgCgTXt25gLQ5LewE1 Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o 1 confirmed ffff
+
+
+## IntelliJ Protobuf Autocompletion
+
+Set the include path:
+
+![](https://i.imgur.com/bDij6Cu.png)
+
+
+## BigTable event persistence
+
+Guardian events can be persisted to a cloud BigTable instance by passing a GCP project and service account key to Tilt.
+Launch the devnet with flags supplying your database info to forward events to your cloud BigTable, rather than the local devnet BigTable emulator:
+
+    tilt up -- --num=1  --gcpProject=your-project-id --bigTableKeyPath=./your-service-account-key.json
+
+## bridge UI
+
+Run the bridge UI in devnet by supplying the `--bridge_ui` flag:
+
+    tilt up -- --bridge_ui
+

Dockerfile.client

@@ -0,0 +1,59 @@
+#syntax=docker/dockerfile:1.2@sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d313c3e2230a333fdbcc
+FROM docker.io/library/rust:1.49@sha256:a50165ea96983c21832578afb1c8c028674c965bc1ed43b607871b1f362e06a5
+
+RUN apt-get update && apt-get install -yq libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang ncat
+RUN curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && apt-get install -y nodejs
+RUN curl -sSfL https://release.solana.com/v1.7.8/install | sh
+
+RUN rustup default nightly-2021-08-01
+RUN rustup component add rustfmt
+
+RUN --mount=type=cache,target=/root/.cache \
+    cargo install --version =2.0.12 spl-token-cli
+
+ENV SOLANA_BIN_PATH="/root/.local/share/solana/install/active_release/bin"
+ENV PATH="$SOLANA_BIN_PATH:$PATH"
+
+ADD ethereum /usr/src/ethereum
+WORKDIR /usr/src/ethereum
+RUN --mount=type=cache,target=/root/.cache \
+	--mount=type=cache,target=/root/.npm \
+    npm ci
+
+ADD clients/token_bridge /usr/src/clients/token_bridge
+WORKDIR /usr/src/clients/token_bridge
+RUN --mount=type=cache,target=/root/.cache \
+	--mount=type=cache,target=/root/.npm \
+	set -xe && \
+	npm ci && \
+	npm run build-contracts && \
+	npm run build
+
+ADD clients/nft_bridge /usr/src/clients/nft_bridge
+WORKDIR /usr/src/clients/nft_bridge
+RUN --mount=type=cache,target=/root/.cache \
+	--mount=type=cache,target=/root/.npm \
+	set -xe && \
+	npm ci && \
+	npm run build-contracts && \
+	npm run build
+
+ADD solana /usr/src/solana
+ADD proto /usr/src/proto
+
+WORKDIR /usr/src/solana
+
+RUN solana config set --keypair "/usr/src/solana/keys/solana-devnet.json"
+RUN solana config set --url "http://solana-devnet:8899"
+
+ENV EMITTER_ADDRESS="11111111111111111111111111111115"
+ENV BRIDGE_ADDRESS="Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o"
+
+RUN --mount=type=cache,target=/root/.cache \
+    --mount=type=cache,target=bridge/target \
+    --mount=type=cache,target=modules/token_bridge/target \
+	set -xe && \
+    cargo build --manifest-path ./bridge/Cargo.toml --package client --release && \
+    cargo build --manifest-path ./modules/token_bridge/Cargo.toml --package client --release && \
+    cp bridge/target/release/client /usr/local/bin && \
+    cp modules/token_bridge/target/release/client /usr/local/bin/token-bridge-client

Dockerfile.lint

@@ -0,0 +1,12 @@
+# syntax=docker.io/docker/dockerfile:experimental@sha256:de85b2f3a3e8a2f7fe48e8e84a65f6fdd5cd5183afa6412fff9caa6871649c44
+FROM docker.io/golang:1.17.0@sha256:06e92e576fc7a7067a268d47727f3083c0a564331bfcbfdde633157fc91fb17d AS go
+
+RUN useradd -u 1000 -U -m -d /home/lint lint
+USER 1000
+WORKDIR /home/lint
+
+RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | \
+	sh -s -- -b ~ v1.42.0
+
+RUN --mount=type=bind,target=/app,source=node cd /app && \
+ 	GOGC=off ~/golangci-lint run --skip-dirs pkg/supervisor ./...

Dockerfile.proto

@@ -0,0 +1,47 @@
+# syntax=docker.io/docker/dockerfile:experimental@sha256:de85b2f3a3e8a2f7fe48e8e84a65f6fdd5cd5183afa6412fff9caa6871649c44
+FROM docker.io/golang:1.17.0@sha256:06e92e576fc7a7067a268d47727f3083c0a564331bfcbfdde633157fc91fb17d AS go-tools
+
+RUN mkdir /app
+
+ADD tools/build.sh /app/tools/
+ADD tools/go.* /app/tools/
+
+RUN --mount=type=cache,target=/root/.cache --mount=type=cache,target=/go \
+	cd /app/tools && CGO_ENABLED=0 ./build.sh
+
+# syntax=docker.io/docker/dockerfile:experimental@sha256:de85b2f3a3e8a2f7fe48e8e84a65f6fdd5cd5183afa6412fff9caa6871649c44
+FROM docker.io/golang:1.17.0@sha256:06e92e576fc7a7067a268d47727f3083c0a564331bfcbfdde633157fc91fb17d AS go-build
+
+COPY --from=go-tools /app /app
+
+ADD buf.* /app
+ADD proto /app/proto
+
+RUN --mount=type=cache,target=/root/.cache \
+	cd /app && \
+	tools/bin/buf lint && \
+	tools/bin/buf generate
+
+FROM node:16-alpine@sha256:004dbac84fed48e20f9888a23e32fa7cf83c2995e174a78d41d9a9dd1e051a20 AS node-build
+
+COPY --from=go-tools /app /app
+
+ADD buf.* /app
+ADD proto /app/proto
+
+ADD tools/package.json /app/tools/
+ADD tools/package-lock.json /app/tools/
+
+RUN --mount=type=cache,target=/root/.cache --mount=type=cache,target=/root/.npm \
+ 	cd /app/tools && npm ci
+
+RUN --mount=type=cache,target=/root/.cache \
+	cd /app && \
+	tools/bin/buf generate --template buf.gen.web.yaml
+
+FROM scratch AS go-export
+COPY --from=go-build /app/node/pkg/proto pkg/proto
+
+FROM scratch AS node-export
+COPY --from=node-build /app/sdk/js/src/proto sdk/js/src/proto
+COPY --from=node-build /app/explorer/src/proto explorer/src/proto

LICENSE

@@ -0,0 +1,13 @@
+Copyright 2020 Wormhole Project Contributors
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.