Contributing to Calyx
Github Workflow
The current home of the Calyx repo can be found here. As with many large projects, we protect the main branch of the repo so that updates can only be made via pull requests. So the development cycle tends to look like:
checkout main -> develop code -> open PR -> revise -> merge PR
For legibility of commits, we squash all commits in a PR down to a single commit
and merge the composite commit to the main branch. This helps keep the commit
count of the main branch lower than it would otherwise be; however, it can make
using commands like git bisect
more challenging for large branches. For that
reason we tend to recommend more frequent PRs to avoid large deltas.
Once your PR has been merged, be sure to check out the updated main branch for future changes. If you branch off the merged branch or continue with it, there will be extensive merge conflicts due to the squash and merge tactic. For this reason we always recommend creating branches off of the main branch if you intend to have them merged into it.
CI Behavior
The CI runs a number of tests including ensuring that Rust and Python code has
been formatted. For Python we use the Black formatter and for Rust we use the
standard cargo fmt
.
For Rust further linting is done via clippy
to ensure that there are
no warnings. In situations where warnings are expected, such as code that is
only part way through development, you can opt to add #[allow]
annotations
within Rust to suppress the lint.
If changes are made to the Dockerfile
then the CI will automatically rebuild
the Docker image and run your tests on it.