Welcome to our community! Thank you for taking the time to read the following.
- All code should have tests.
- All code should be documented.
- No changes are ever committed without review and approval.
- github is used for the code base.
- For a PR to be integrated, it must be approved at least by one core team member.
- Development discussions happen on Discord but any request must be formalized in github. This ensures a common history.
- Continuous Integration is provided by Github actions and configuration is located at
.github/workflows
.
After cloning the repository, see the various Makefiles.
Testing your code is paramount. Without continuous integration, we cannot
guaranty the quality of the code. Some minor modification on a function can
have unexpected implications. With a single commit, everything can go south!
The main
branch is always on a passing state: CI is green, working code,
and an installable Python package.
Tests will be automatically launched when you will push your branch to GitHub. Be mindful of this resource!
Apart from normal unit and integration tests, you can perform a static analysis of the code using black and ruff for Python, prettier for JS/MD/MDX and standard Rust formatters.
This allows to spot naming errors for example as well as other style errors.
The development model is based on the Cactus Model also called Trunk Based Development model. More specificaly, we use the Scaled Trunk-Based Development model.
Some additional ressources: gitflow, gitflow critique, github PR.
It means that each new feature has to go through a new branch. Why? For peer review. Pushing directly on the develop without review should be exceptional (hotfix)!
This project is using pre-commit hooks. So you have to set it up like this:
pre-commit install
pre-commit run --all-files
When you try to commit your changes, it will launch the pre-commit hooks
(.pre-commit-config.yaml
)
and modify the files if there are any changes to be made for the commit to be
accepted. If you don't use this feature and your changes are not compliant
(linter), CI will fail.
If you want to add a modification, create a new branch branching off main
.
Then you can create a merge request on github. From here, the fun begins.
For every commit you push, the linter and tests are launched.
Your request will only be considered for integration if in a finished state:
- Respect Python/JS/Rust coding rules,
- Have tests regarding the changes,
- The branch passes all tests (current and new ones),
- Maintain test coverage,
- Have the respective documentation.
Commit messages should be clear and follow a few basic rules. Example:
Add functionality X.
Lines shouldn't be longer than 72
characters. If the commit is related to a ticket, you can indicate that
with "See #3456", "See ticket 3456", "Closes #3456", or similar.
Describing the motivation for a change, the nature of a bug for bug fixes or
some details on what an enhancement does are also good to include in a commit
message. Messages should be understandable without looking at the code
changes. A commit message like fixed another one
is an example of
what not to do; the reader has to go look for context elsewhere.
Squash-merge is systematically used to maintain a linear history. It's important to check the message on the squash commit.
Following is the process that the development team follows in order to make a release:
- Update the version in the main
pyproject.toml
. - Build locally using
hatch build
, and verify the content of the artifacts - Submit PR, wait for tests to pass, and merge release into
main
- Trigger manually the release workflows
- Check that release has been deployed to PyPI
- Upload the WASM for the smart contract