Development

Workflows

Ledger provides reusable workflows running on GitHub actions, which builds, analyzes or tests the code, checks the application’s metadata and more. Some of these workflows are mandatory.

• The guidelines enforcer workflow (example its usage on boilerplate here)
• The build workflow (example of its usage on boilerplate here)

Manifest

Some high-level application metadata must be declared in a ledger_app.toml manifest file, stored at the root of the application repository.

The format of this manifest is described here, along with the tool which can be used to check the validity of the manifest. You can also use the manifest in Boilerplate as a living example

Most of our workflows (including the mandatory ones) use this manifest to infer environment data (like the SDK language, or the build directory) so the validity of the manifest can be checked through these.

Tests

The application repository must have a tests folder that contains at least functional tests using the Speculos emulator. These tests must be triggered by the CI and running without error.

For Python tests, Ledger provides the Ragger library, which can be easily integrated with Pytest in the GitHub action with the Ragger workflow (example of its usage on boilerplate here)

Unit tests are highly recommended, especially for critical functions like parsers - preferably relying on a standard framework like cmocka. These tests must be automated using GitHub actions the unit tests workflow of the Boilerplate application can act as a reference.

Nice to have

On top of that, we also encourage the following practices:

• Linting helps improving code quality and ensuring consistent coding style and resolving basic coding errors.
• Developing a fuzzer (example of its usage on boilerplate here).
• Integration with the Coverity static code analysis tool helps finding security issues and software defects.