We ❤️ every form of contribution. The following document aims to provide enough context to work with our codebase and to open pull requests that follow our conventions. If this document does not provide enough help, open a new issue and we'll gladly help you get started.
You can build the whole platform using the following command:
and build a specific project like so:
To run tests, execute the following command:
You can also run tests of a specific project like so:
You can lint the entire code base by executing the
We use language specific linters:
- buildifier to lint Bazel Starlark files
- CheckStyle for Java
Java, buildifier and prettier are ran as test targets for each package, so you can run:
You can also run:
to try fixing issues automatically (not supported for checkstyle).
If you add, remove, or change a dependency from the maven_install, you must re-pin dependencies using the following command:
Bazel has an extensive query language you can use to dig deeper into projects. Here are a few examples:
If you are not familiar with a specific project, you can also run the following query:
The query shows all the targets produced under that specified package. It can help getting started.
Bazel also offers a friendly and powerful autocompletion, please refer to this document to install it locally.
You can test your images locally at runtime if you have a local instance of Airy Core running in Minikube.
In order for the Airy Core cluster to have access to a newly built image, you need to publish the image to Minikube's (built-in) docker registry. Do this by pointing your shell's docker environment to the docker instance in minikube:
Next, create an image with bazel, which will automatically load the image into Minikube's registry. For example:
You can verify this action with
docker images and you can restore the shell
environment to point to your local docker instance with
eval $(minikube -p airy-core docker-env -u).
Next, you will want to run this image in the Airy Core cluster. For this example that means you need to:
Once this is done, the image will be up and running in your local cluster.
In order to organize our releases in the best possible way, we follow a few critical conventions.
Branches must abide to the following format:
branch-type is defined as follows:
featare used for feature branches
hotfixare used for bug fixes
docsare used for documentation changes
choreis used for maintenance tasks on the repo
description field must use kebab case.
Given these conventions here are a few examples:
To keep a clean track of what is being released, every feature must contain only one commit when merged. The commit message of the squashed commit is very important, since it will be used to keep track of the features in a release.
The conventional format is:
[#issue] - description. For the example, if your
pull request refers to the issue "Introduce meaning of life" with number 42,
the squashed commit message must be: