Testing the system update flow on a board currently takes a manual setup for the scenario where we want to test a build as available upgrade.
Manual steps:
build the package, give it a version that outranks the released one, copy it over, turn the destination into an apt repository and register it as a source.
The task command should automate that setup so that, once run, a system update on the board offers the locally built version as the available upgrade.
What it does
- Builds the debian package from the current working tree.
- Assigns it a version high enough to win over whatever the official repository offers, so apt picks the local build as the candidate.
- Copies it to the board, into a location that survives a reboot.
- Generates the package index next to it and registers the directory as an apt source, so apt treats it as a normal repository.
After that the board is ready: triggering an update through the daemon, the CLI, or the app installs the code under test.
Notes:
- The package must come from the working tree, not from a release: the update path also depends on files shipped by the package itself, so both ends of the upgrade have to carry the code under test.
- Worth a companion task to remove the source and the directory, to put the board back to following the official repository.
Testing the system update flow on a board currently takes a manual setup for the scenario where we want to test a build as available upgrade.
Manual steps:
build the package, give it a version that outranks the released one, copy it over, turn the destination into an apt repository and register it as a source.
The task command should automate that setup so that, once run, a
system updateon the board offers the locally built version as the available upgrade.What it does
After that the board is ready: triggering an update through the daemon, the CLI, or the app installs the code under test.
Notes: