Skip to content

Latest commit

 

History

History
120 lines (80 loc) · 5.42 KB

CONTRIBUTING.md

File metadata and controls

120 lines (80 loc) · 5.42 KB
Raw

Contributing

Welcome ! and thanks for landing here. We are currently in the first stages of this project. Your contributions, in any point of the wide spectrum ideas, opinions, code .. Are more than welcome.

We just must follow this initially established (but not fixed) conventions.

Conventions

  • We have defined some conventions for dealing with the rough edges of our Rust wrapper code. They must be followed, unless new agreements are met.
  • Keep all repository workflows in the internal CLI.
  • We use Github Actions for the CI/CD, as long as it's maintainable and practical. We try to avoid putting lots of logic there by moving it to our CLI.
  • All knowledge should be added to our wiki and maintained.
  • No functionality is implemented, only translated from the librustzcash library. As such, we may only accept contributions that respect this principle.

Development procedure

  • Most code contributions must be in form of PRs originated in contributors repository forks.
  • Small, direct PRs are encouraged.
  • If a BIG idea is around, please, its better to create a new issue first and ask for feedback.

Using the repo CLI

This CLI allows to easy setup, build and publish the bindings and packages. We encourage to read the in crate documentation.

Local environment setup

MacOS

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup default nightly
rustup update

brew install kotlin
brew install kylef/formulae/swiftenv
brew install python
brew install ruby
brew install wget

Use swiftenv to setup a system wide swift version.

In case of problems, re-check:

  • Ensure ruby has an user writable path for storing gems. Sometimes this needs to be setup by: 
    export GEM_HOME="$HOME/.gem"
  • By default, you could be using the default system ruby installation (check with which ruby ) if not pointing to homebrew, this needs to be setup: 
    export PATH="/opt/homebrew/opt/ruby/bin:$PATH"
  • Ensure x-code tools are properly installed with developer tools: xcode-select --install.
  • Ensure your SDKROOT environment variable is configured.

Linux

# Kotlin
sudo apt install default-jdk # if you still don't have Java installed
curl -s https://get.sdkman.io | bash # restart the terminal after this
sdk install kotlin

# Ruby
sudo apt-get install ruby-full

# Swift
# Download, un-tar, put in the path the binary from (here) <https://www.swift.org/download>.

# Python
sudo apt-get install python3.x # 3.8, 3.9

# Others
sudo apt-get install wget

Docker setup

There is a Docker image for development on emulated system, but at the moment only for M1 - although it's easily configurable for other architectures. We'll make a set of instructions available for it.

Testing

All the tests are located in the testing directory.

Executing the tests

Ensure the Sapling crypto parameters are downloaded. You can download them to your $home with the in repo CLI by:

$ cargo run -p uniffi-zcash-cli setup saplingparams

Then the tests can be run by:

$ cargo test

Data driven tests

Having a different dataset per each language would make no sense since we are testing exactly the same functionality on each language. It would be hard to maintain. In order to address this, we developed data generators and a common data key value store that can be used from all the languages.

Test data generation

A CSV file with test data is committed in the repo. In case a new test is added or a modification is done in any of them, the new data should be committed.

If its needed to add new data generators or modifying the actual golden file you can execute from the lib folder of the repo:

$ cargo run -p uniffi-zcash-cli setup saplingparams

More details available in the CLI docs

Releasing a new version

This repo follows trunk based development workflow. It means we move features directly to main assuming all the checks passed at that point. Then the main branch is tagged when we reach a release point with a semver compliant tag. Lets note here, a valid tag is 1.0.0 not v1.0.0. The tag action will ultimately trigger the package generation and publishing.

important note: Generated documentation should be taken into account during this process. It can be generated with the CLI. At the time of this write, its unclear if it should be committed in the repo, thus prepared before tagging or should uploaded to another system.