The Foundry project is organized as a regular Cargo workspace.
- Rust
- Make
We use cargo-nextest as test runner (both locally and in the CI):
If you are working in VSCode, we recommend you install the rust-analyzer extension, and use the following VSCode user settings:
"editor.formatOnSave": true,
"rust-analyzer.rustfmt.extraArgs": ["+nightly"],
"[rust]": {
"editor.defaultFormatter": "rust-lang.rust-analyzer"
}Note that we use Rust's latest nightly for formatting. If you see ; being inserted by your code editor it is a good indication you are on stable.
Build the project.
$ make buildRun all tests.
$ make testRun all tests and linters in preparation for a PR.
$ make prNote: This is incomplete and possibly outdated
See also Getting Help
Whenever a ticket is initially opened a T-needs-triage label is assigned. This means that a member has yet to correctly label it.
If this is your first time contributing have a look at our first-issue tickets. These are tickets we think are a good way to get familiar with the codebase.
We classify the tickets in two major categories: T-feature and T-bug. Additional labels are usually applied to help categorize the ticket for future reference.
We also make use of T-meta aggregation tickets. These tickets are tickets to collect related features and bugs.
We also have T-discuss tickets that require further discussion before proceeding on an implementation. Feel free to jump into the conversation!
We use GitHub Actions for continuous integration (CI).
We use cargo-nextest as the test runner.
If make test passes locally, that's a good sign that CI will be green as well.
Nightly/stable release builds derive their enabled functionality from the shared RUST_FEATURES environment variable in .github/workflows/release.yml and .github/workflows/docker-publish.yml. Keep that list aligned with the default FEATURES value in the root Makefile so published artifacts expose the same CLI surface area (wallet backends, allocators, tracers, etc.) as local builds.