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 run 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
repositories.bzl, you must
re-pin dependencies using the following command:
We use Gazelle to manage golang based projects and dependencies in our code.
Gazelle allows you to work within a projects directory as if it were a regular golang project.
After changing code or adding/removing dependencies you have to run
bazel run //:gazelle in order to update the project's
One essential advantage of mono repositories is that they allow you to deliver one version of each external dependency across the entire company.
This is however outside the scope of Gazelle which only takes care of syncing build files and does not take into account a global dependency structure.
Therefore, if you updated a subproject's
go.mod file you need to run a custom tool that we built in order to perform the merge:
You can learn more about how it works here.
update-deps tool uses gazelle to update the global
go_repositories.bzl file adding one
go_repository rule for each dependency.
When encountering a build issue you can go through the following steps to try to solve it:
- Use community resources: Gazelle docs, Golang module docs, the #go channel of the Bazel slack
- Each dependency has an
importpaththat needs to be unique, e.g.
sigs.k8s.io/json. If there is a build conflict within the dependencies it is likely that some dependency is out of date and brings in a sub-dependency with a conflicting import path.
- Load order: Bazel reads the
WORKSPACEfile in a sequential manner. That means if some rule is loaded before our call to
go_repositories()it would overwrite the version of a go module that we are trying to load. This behavior is improved in Bazel's new module system.
go mod graphto understand who is bringing in a dependency. This can be useful to understanding why a troublesome dependency is imported and how to update it.
- Check that the
build_file_proto_modeis set to
disable_globalfor the dependency that is causing the issue. It is currently set to this value by default when running the
update-depstool, but Gazelle is capable of tracking some custom changes that you make to this file.
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
enhancementis used for improvements of existing features
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 (
Description must start with a capital letter). For the example, if your
pull request refers to the issue "Introduce meaning of life" with number 42,
the squashed commit message must be: