Contributions to Marathon’s source are welcome! Here is a quick guide where to start.
Then checkout the marathon repository and open the project in your IDE.
All the issues are tracked in GitHub, so check the issue tracker and project board for a list of something to work on. Alternatively you can submit an issue and then work on it. Before you do that you’re highly encouraged to check if this issue is not already closed and talk with us using our slack channel.
Once you pick your issue please assign yourself to work on it.
All the issues relevant to a specific version are assigned to a GitHub milestone so if the issue you’re working on is required to fixed for the next version we’ll add it to the current milestone.
You can get the source code of marathon by cloning the repo.
git clone https://github.com/MarathonLabs/marathon.git
If you plan to submit changes to the repo then please fork the project in GitHub. If you commit frequently then we can add you to the main repository also.
Marathon’s project has built-in run configurations for executing included sample projects:
You can use this setup to quickly debug something on a sample app or you can change the workdir of the configuration and debug your own codebase. Default configurations for IntelliJ use CLI version of marathon.
While working on an issue it’s much faster to use CLI distribution which you can build using the
:cli:installDist task in gradle. This
task builds marathon binary with all of its dependencies. The output binary can be found at
If you use this output frequently consider changing your
If you want to create a distributable zip:
$ ./gradlew :cli:distZip $ ls cli/build/distributions marathon-X.X.X-SNAPSHOT.zip
In order to test gradle plugin changes we install all modules into a maven structured folder. Unfortunately you can’t use gradle plugins with SNAPSHOT version, so in order to test your changes via gradle plugin you have to publish a release version of marathon which gets quite cumbersome, that’s why preferred method of testing for development purposes is the CLI.
In order to install all packages into build/repository folder you need to
./gradlew publishDefaultPublicationToLocalRepository -PreleaseMode=RELEASE
After that you need to sync your project. By default, all sample projects depend on this local folder and pick up marathon from there. If it’s not working check that you actually built everything related to the plugin and the version that you specified in sample project and the one that’s published match.
Before trying to execute real tests try executing unit and integration tests via
./gradlew clean test jacocoTestReport integrationTest
command. Assuming everything passes check relevant sample project where you can test your changes. If your change is related to the core
part then you must check that both android and ios vendor implementations will not be affected.
Before pushing your changes please check if our linter (detekt) passes via
./gradlew clean detektCheck command.
core - This is the main logic part of the runner.
marathon-gradle-plugin - This is a gradle plugin implementation for Android testing
vendor - This is custom vendor implementation related to specific platform. One specific implementation that is important is vendor-test, this is a fake implementation that we’re using for integration testing
report - This is a group of modules which implement various reports that marathon generates after the build
cli - This is the command-line interface wrapper for Marathon
analytics:usage - This is an analytics implementation that we’re using for tracking anonymised usage of marathon.
We’re available for any questions or proposals on Slack. Feel free to join!