Checks appup coverage against the modules that changed between two builds.
mix castle.appup --from <spec> [--to <spec>] [--app <app>]...The task is read-only and exits non-zero when it finds a coverage error. Use it
as a release-pipeline check. mix castle.appup.gen accepts the same build and
application options and drafts missing entries.
Builds
--from is required. --to defaults to the current compiled build. Both
switches accept a baseline spec:
mix castle.appup --from rel:_build/prod/rel/my_app/releases/1.0.0/my_app
mix castle.appup --from tar:artifacts/my_app-1.0.0.tar.gz
mix castle.appup --from ref:1.0.0A path without a prefix means rel:. Prefer tar: when the shipped artifact
is available. A rebuilt baseline may differ from the deployed release.
Repeat --app to select applications. The default is the current project and
its umbrella children. Name a dependency explicitly to check its appup.
Results
Upgrade and downgrade directions are checked separately. The task reports:
- a changed or added module that no instruction loads;
- a removed module that no instruction deletes;
- a module that an edge both loads and removes;
- duplicate instructions for one module;
- a module deleted while still present in the target;
- a changed module absent from the application's
.appinventory; - invalid instructions or a missing entry for the from-version;
- code changes without an application version change.
An instruction for an unchanged module is reported but does not fail the run. An edge that restarts the emulator needs no module-level coverage.
This task checks coverage. Relup generation determines whether :systools
accepts the complete script. An invalid instruction is credited with no
coverage, but a successful check does not guarantee that a relup will build.
Module fingerprints combine the BEAM md5 with persisted attributes. This
ignores stripping and documentation changes while retaining explicit @vsn
changes.
The task requires a baseline, so it belongs in the release pipeline rather
than mix precommit.