This [github document](https://help.github.com/articles/creating-a-pull-request/) provides some guidance on how to create a pull request in github.
This [github document](https://help.github.com/articles/creating-a-pull-request/) provides some guidance on how to create a pull request in github.
## PR requirement
## PR requirement
To pursue engineering excellence, we have insisted on the highest standard for the quality of each PR.
To pursue engineering excellence, we have insisted on the highest stardard on the quality of each PR.
* For each PR, please run [golint](https://github.com/golang/lint), [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports), to fix the basic issues/warnings.
* For each PR, please run [golint](https://github.com/golang/lint), [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports), to fix the basic issues/warnings.
* Make sure you understand [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
* Make sure you understand [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
@ -21,12 +21,12 @@ To pursue engineering excellence, we have insisted on the highest standard for t
The best practice is to reorder and squash your local commits before the PR submission to create an atomic and self-contained PR.
The best practice is to reorder and squash your local commits before the PR submission to create an atomic and self-contained PR.
This [book chapter](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) provides detailed explanation and guidance on how to rewrite the local git history.
This [book chapter](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) provides detailed explanation and guidance on how to rewrite the local git history.
For example, a typical workflow is like the following.
For exampple, a typical workflow is like the following.
```bash
```bash
# assuming you are working on a fix of bug1, and use a local branch called "fixes_of_bug1".
# assuming you are working on a fix of bug1, and use a local branch called "fixes_of_bug1".
git clone https://github.com/woop-chain/woop
git clone https://github.com/harmony-one/harmony
cd woop
cd harmony
# create a local branch to keep track of the origin/master
# create a local branch to keep track of the origin/master
@ -39,27 +47,27 @@ For macOS, you can reference this [guide](http://tldrdevnotes.com/bash-upgrade-3
## Dev Environment
## Dev Environment
**Most repos from [woop-chain](https://github.com/woop-chain) assumes the GOPATH convention. More information [here](https://github.com/golang/go/wiki/GOPATH).**
**Most repos from [harmony-one](https://github.com/harmony-one) assumes the GOPATH convention. More information [here](https://github.com/golang/go/wiki/GOPATH).**
### First Install
### First Install
Clone and set up all of the repos with the following set of commands:
Clone and set up all of the repos with the following set of commands:
Included in this repo is a Dockerfile that has a full woop development environment and
Included in this repo is a Dockerfile that has a full harmony development environment and
comes with emacs, vim, ag, tig and other creature comforts. Most importantly, it already has the go environment
comes with emacs, vim, ag, tig and other creature comforts. Most importantly, it already has the go environment
with our C/C++ based library dependencies (`libbls` and `mcl`) set up correctly for you.
with our C/C++ based library dependencies (`libbls` and `mcl`) set up correctly for you.
You can build the docker image for yourself with the following commands:
You can build the docker image for yourself with the following commands:
```bash
```bash
cd $(go env GOPATH)/src/github.com/woop-chain/woop
cd $(go env GOPATH)/src/github.com/harmony-one/harmony
make clean
make clean
docker build -t woop .
docker build -t harmony .
```
```
> If your build machine has an ARM-based chip, like Apple silicon (M1), the image is built for `linux/arm64` by default. To build for `x86_64`, apply the `--platform` arg like so:
> If your build machine has an ARM-based chip, like Apple silicon (M1), the image is built for `linux/arm64` by default. To build for `x86_64`, apply the `--platform` arg like so:
> Learn more about the `--platform` arg and multi-CPU architecture support, [here](https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope) and [here](https://docs.docker.com/desktop/multi-arch/).
> Learn more about the `--platform` arg and multi-CPU architecture support, [here](https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope) and [here](https://docs.docker.com/desktop/multi-arch/).
@ -89,26 +97,26 @@ docker build -t woop .
Then you can start your docker container with the following command:
Then you can start your docker container with the following command:
> Note that the woop repo will be shared between your docker container and your host machine. However, everything else in the docker container will be ephemeral.
> Note that the harmony repo will be shared between your docker container and your host machine. However, everything else in the docker container will be ephemeral.
If you need to open another shell, just do:
If you need to open another shell, just do:
```bash
```bash
docker exec -it woop /bin/bash
docker exec -it harmony /bin/bash
```
```
Learn more about docker [here](https://docker-curriculum.com/).
Learn more about docker [here](https://docker-curriculum.com/).
## Build
## Build
The `make` command should automatically build the Woop binary & all dependent libs.
The `make` command should automatically build the Harmony binary & all dependent libs.
However, if you wish to bypass the Makefile, first export the build flags:
However, if you wish to bypass the Makefile, first export the build flags:
To keep things consistent, we have a docker image to run all tests. **These are the same tests ran on the pull request checks**.
To keep things consistent, we have a docker image to run all tests. **These are the same tests ran on the pull request checks**.
Note that all test Docker containers bind several ports to the host machine for your convenience. The ports are:
Note that all testing docker container binds a couple of ports to the host machine for your convince. The ports are:
* `9500` - Shard 0 RPC for a validator
* `9500` - Shard 0 RPC for a validator
* `9501` - Shard 1 RPC for a validator
* `9501` - Shard 1 RPC for a validator
* `9599` - Shard 0 RPC for an explorer
* `9599` - Shard 0 RPC for an explorer
@ -151,7 +159,7 @@ Note that all test Docker containers bind several ports to the host machine for
* `9798` - Shard 1 Rosetta (for an explorer)
* `9798` - Shard 1 Rosetta (for an explorer)
* `9899` - Shard 0 WS for an explorer
* `9899` - Shard 0 WS for an explorer
* `9898` - Shard 1 WS for an explorer
* `9898` - Shard 1 WS for an explorer
> This allows you to use curl, wiki CLI, postman, rosetta-cli, etc... on your host machine to play with or probe the localnet that was used for the test.
> This allows you to use curl, hmy CLI, postman, rosetta-cli, etc... on your host machine to play with or probe the localnet that was used for the test.
### Go tests
### Go tests
To run this test, do:
To run this test, do:
@ -166,8 +174,8 @@ To run this test, do:
make test-rpc
make test-rpc
```
```
This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs a series of tests to ensure correct RPC behavior.
This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs a series of tests to ensure correct RPC behavior.
This test also acts as a preliminary integration test (more thorough tests are done on the testnets).
This test also acts as a preliminary integration test (more through tests are done on the testnets).
> The tests ran by this command can be found [here](https://github.com/woop-chain/woop-test/tree/master/localnet).
> The tests ran by this command can be found [here](https://github.com/harmony-one/harmony-test/tree/master/localnet).
If you wish to debug further with the localnet after the tests are done, open a new shell and run:
If you wish to debug further with the localnet after the tests are done, open a new shell and run:
```bash
```bash
@ -175,9 +183,9 @@ make test-rpc-attach
```
```
> This will open a shell in the docker container that is running the Node API tests.
> This will open a shell in the docker container that is running the Node API tests.
>
>
> Note that the docker container has the [Woop CLI](https://docs.wikiwoop.com/home/wallets/woop-cli) on path,
> Note that the docker container has the [Harmony CLI](https://docs.harmony.one/home/wallets/harmony-cli) on path,
> therefore you can use that to debug if needed. For example, one could do `wiki blockchain latest-headers` to check
> therefore you can use that to debug if needed. For example, one could do `hmy blockchain latest-headers` to check
> the current block height of localnet. Reference the documentation for the CLI [here](https://docs.wikiwoop.com/home/wallets/woop-cli)
> the current block height of localnet. Reference the documentation for the CLI [here](https://docs.harmony.one/home/wallets/harmony-cli)
> for more details & commands.
> for more details & commands.
### Rosetta tests
### Rosetta tests
@ -186,8 +194,8 @@ To run this test, do:
make test-rosetta
make test-rosetta
```
```
This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs the Construction & Data API checks using the [rosetta-cli](https://github.com/coinbase/rosetta-cli).
This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs the Construction & Data API checks using the [rosetta-cli](https://github.com/coinbase/rosetta-cli).
This test also acts as a preliminary integration test (more thorough tests are done on the testnets).
This test also acts as a preliminary integration test (more through tests are done on the testnets).
> The config for this test can be found [here](https://github.com/woop-chain/woop-test/blob/master/localnet/configs/localnet_rosetta_test_s0.json) & [here](https://github.com/woop-chain/woop-test/blob/master/localnet/configs/localnet_rosetta_test_s1.json)
> The config for this test can be found [here](https://github.com/harmony-one/harmony-test/blob/master/localnet/configs/localnet_rosetta_test_s0.json) & [here](https://github.com/harmony-one/harmony-test/blob/master/localnet/configs/localnet_rosetta_test_s1.json)
Similar to the RPC tests, if you wish to debug further with the localnet after the tests are done, open a new shell and run:
Similar to the RPC tests, if you wish to debug further with the localnet after the tests are done, open a new shell and run:
```bash
```bash
@ -196,10 +204,10 @@ make test-rosetta-attach
## License
## License
Woop is licensed under GNU Lesser General Public License v3.0. See [`LICENSE`](LICENSE) file for
Harmony is licensed under GNU Lesser General Public License v3.0. See [`LICENSE`](LICENSE) file for
the terms and conditions.
the terms and conditions.
Woop includes third-party open-source code. In general, a source subtree
Harmony includes third-party open-source code. In general, a source subtree
with a `LICENSE` or `COPYRIGHT` file is from a third party, and our
with a `LICENSE` or `COPYRIGHT` file is from a third party, and our
modifications thereto are licensed under the same third-party open source
modifications thereto are licensed under the same third-party open source
license.
license.
@ -208,7 +216,7 @@ Also please see [our Fiduciary License Agreement](FLA.md) if you are
contributing to the project. By your submission of your contribution to us, you
contributing to the project. By your submission of your contribution to us, you
and we mutually agree to the terms and conditions of the agreement.
and we mutually agree to the terms and conditions of the agreement.
## Contributing To Woop
## Contributing To Harmony
See [`CONTRIBUTING`](CONTRIBUTING.md) for details.
See [`CONTRIBUTING`](CONTRIBUTING.md) for details.
@ -227,3 +235,10 @@ See [`CONTRIBUTING`](CONTRIBUTING.md) for details.
“GheisMohammadi”