Contributing to Spin

We are delighted that you are interested in making Spin better! Thank you! This document will guide you through making your first contribution to the project.

First, any contribution and interaction on any Fermyon project MUST follow our code of conduct. Thank you for being part of an inclusive and open community! We welcome and appreciate contributions of all types — opening issues, fixing typos, adding examples, one-liner code fixes, tests, or complete features.

If you plan on contributing anything complex, please go through the issue and PR queues first to make sure someone else has not started working on it. If it doesn’t exist already, please open an issue so you have a chance to get feedback from the community and the maintainers before you start working on your feature.

Making code contributions to Spin

The following guide is intended to make sure your contribution can get merged as soon as possible. First, make sure you have the following prerequisites configured:

Once you have set up the prerequisites and identified the contribution you want to make to Spin, make sure you can correctly build the project:

# clone the repository
$ git clone && cd spin
# add a new remote pointing to your fork of the project
$ git remote add fork<your-username>/spin
# create a new branch for your work
$ git checkout -b <your-branch>

# if you are making a documentation contribution,
# you can skip compiling and running the tests.

# build a release version of the Spin CLI
$ cargo build --release
# make sure compilation is successful
$ ./target/release/spin --help

# run the tests and make sure they pass
$ make test

Now you should be ready to start making your contribution. To familiarize yourself with the Spin project, please read the document about extending Spin. Since most of Spin is implemented in Rust, we try to follow the common Rust coding conventions (keep an eye on the recommendations from Clippy!) If applicable, add unit or integration tests to ensure your contribution is correct.

Build the project and run the tests (make build test), and if everything is successful, you should be ready to commit your changes. We try to follow the Conventional Commits guidelines for writing commit messages:

$ git commit -S -s -m "<your commit message that follows>"

We try to only keep useful changes as separate commits — if you prefer to commit often, please cleanup the commit history before opening a pull request. Once you are happy with your changes you can push the branch to your fork:

# "fork" is the name of the git remote pointing to your fork
$ git push fork

Now you are ready to create a pull request. Thank you for your contribution!