You can contribute code or documentation to the toolkit. This document will guide you through the process or picking a task and building the code.
- You can check available tasks in the Project Board or the Organization Board. Issues with the
help wanted tag in the
Readycolumn are recommended for a first time contribution.
- Claim an issue you want to work in with a comment (after that I can assign it to you and move it
Workingcolumn. If you want to contribute to a non tagged (or a non existing) tasks: write a comment, and we'll discuss the scope of the feature.
- New features should be discussed within an issue in the issue tracker before actual coding. You may do a PR directly, but you take the risk of it being not suitable and discarded.
- For code, file names, tags and branches use either camel case or snake case only. I.e.: avoid
.in file names if it is possible.
- For a Pull Request to be accepted, follow the pull request template recommendations. Check the
code follows the Kotlin Coding Conventions, except final brace position in
finally(in its own line). If you use IntelliJ and Editor Config this will be checked for you.
- Follow the commit rules defined at the commit template.
- Bug format: when filing bugs please comply with the bug template requirements.
- A feature requests should follow the enhancement template rules.
The Hexagon project is composed of several modules. Most of the modules publish libraries for their use by other projects (check the Hexagon Structure section of the readme file for more details).
Aside of that kind of modules, you can also find infrastructure modules: components used by the project itself. These are internal modules not intended to be directly used by users (like the hexagon_starters or the hexagon_site).
Hexagon build process requires Docker Compose installed
You can check the required software, build the project, generate the documentation and install it in your local repository typing:
1 2 3
The binaries are located in the
/build directory of each module. The documentation site is in
To work more comfortable, you can define some useful aliases like:
Other useful Gradle commands (assuming
alias gw='./gradlew') are:
- Module Tasks:
gw [module:]tasks [--all]
- Task details:
gw help --task <task>
gw clean assemble
gw clean build
It is recommended that you create a Git pre-push script to check the code before pushing it. As this command will be executed before pushing code to the repository (saving you time fixing GitHub Actions build errors).
This can be done executing the
setUp task by running:
rabbitmq container to work properly, you should follow the
Docker setup documentation (inside the "With Docker" section)
If you want to generate the documentation site, check the site module readme
If you get a dependency verification error building the project after adding or changing a
dependency, you need to add the key fingerprint inside the
trusted-keys element at the
Prior to trusting the key, you should verify it belongs to the person it claims to be on the
http://keys.gnupg.net key search tool. I.e.: you can check the Hexagon fingerprint
792B D37F F598 91C4 AC6F 8D92 3B26 711D 2AEE 3721) issuing [this search] (don't forget to add
0x before the fingerprint without spaces).
For Continuous Integration runners, you need to import the keys inside the
gradle/verification-keyring.gpg file, you can do so with the following command:
```shell script gpg --no-default-keyring --keyring ./gradle/verification-keyring.gpg --recv-keys $fingerprint
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36