Development
Workflows
Ledger provides reusable workflows running on GitHub actions (opens in a new tab), which builds, analyzes or tests the code, checks the application's metadata and more. Some of these workflows are mandatory.
The following workflows are required on every device app repository, and must run without error.
Ledger will not deploy an application if these workflows are not integrated and green.
- The guidelines enforcer workflow (opens in a new tab) (example its usage on boilerplate here (opens in a new tab))
- The build workflow (opens in a new tab) (example of its usage on boilerplate here (opens in a new tab))
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 (opens in a new tab), along with the tool which can be used to check the validity of the manifest. You can also use the manifest in Boilerplate (opens in a new tab) 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.
Ledger will not deploy an application without a correct ledger_app.toml manifest.
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.
Ledger will not deploy an application without tests or with failing tests.
For Python tests, Ledger provides the Ragger library (opens in a new tab), which can be easily
integrated with Pytest in the GitHub action with the Ragger workflow (opens in a new tab)
(example of its usage on boilerplate here (opens in a new tab))
Unit tests are highly recommended, especially for critical functions like parsers - preferably relying on a standard framework like cmocka (opens in a new tab). These tests must be automated using GitHub actions the unit tests workflow (opens in a new tab) 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 (opens in a new tab)).
- Integration with the Coverity static code analysis tool helps finding security issues and software defects.
