Contributing to this repo can mean many things such as participating in discussion or proposing code changes. Following the processes outlined in this document will lead to the best chance of getting changes merged into the codebase.
When proposing an architecture decision for Gaia, please start by opening an issue or a discussion with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, you may either start development, or write an ADR.
If your architecture decision is a simple change, you may contribute directly without writing an ADR. However, if you are proposing a significant change, please include a corresponding ADR.
To create an ADR, follow the template and doc. If you would like to see examples of how these are written, please refer to the current ADRs.
Tests can be executed by running make test at the top level of the Sekai repository.
Before submitting a pull request:
- synchronize your branch with the latest
masterbranch and resolve any arising conflicts,git fetch origin/master && git merge origin/master - run
make install,make test, to ensure that all checks and tests pass.
In order to accommodate the review process, the author of the PR should be in contact with Sekai repo maintainers.
Changelog keeps the changes made as part of releases. The logs are kept on CHANGELOG.
We use Go Modules to manage dependency versions.
The main branch of every Cosmos repository should just build with go get,
which means they should be kept up-to-date with their dependencies so we can
get away with telling people they can just go get our software.
When dependencies in Sekai's go.mod are changed, it is generally accepted practice
to delete go.sum and then run go mod tidy.
Since some dependencies are not under our control, a third party may break our
build, in which case we can fall back on go mod tidy -v.
We use Protocol Buffers along with gogoproto to generate code for use in sekai.
For deterministic behavior around Protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to Docker's website to install it.
To generate the protobuf stubs, you can run make proto-gen.
Sekai branches should be one of feature/{feature-description} or bugfix/{bugfix-description} to join CI/CD process.
Sekai follows semantic versioning.
To release a new version
- Set a new sekai version on
types/constants.go - Add relevant information on
RELEASE.md - Push the code to the branch
- The bot automatically creates release branch
release/vx.x.xas configured intypes/constants.goand raise the PR from working branch to release branch automatically - Check CI/CD pass on the PR
- Get manual review
- Get the PR merged into release branch
- New PR into master is raised after release branch PR merge
- Check CI/CD pass on the PR
- Merge into master