Over-the-Air Updates

The previous section describes where each version's source code is stored on the local device.

"Config" vs. "Foreign Config"

There are two types of configuration schemas:

1. Config - the schema that the current version of your DAS requires to run: see API reference
2. Foreign Config - the schema that is required by any configuration that the current DAS version should upgrade to.

This means you can change almost the entire structure of your config when developing a new DAS version - you only have to keep the fields general.config_revision and general.software_version.

Update Steps

Whenever a new config comes, the updater executes the following steps:

1. Check whether this config revision has already been processed.
2. If version is equal to the current version:
   • Parse the received config file string using types.Config.load_from_string
   • If the received config is equal to the current config:
     • do nothing
   • Otherwise:
     • dump the received config to the config file path
     • exit with status code 0
3. If version is not equal to the current version:
   • Download the source code of the new version
   • Create a new virtual environment (in the new version's subdirectory)
   • Install dependencies using pdm sync
   • Dump the received config to the config file path
   • Run the pytests for the pytest marker integration
   • Update the cli pointer
   • Exit with status code 0

Hence, when it is a reconfiguration, the new config will be accepted if it passes the config validation. When it is a version change, it will only be accepted if all pytests with the pytest mark integration pass on the local device. Feel free to add more tests in tests/integration/.

If any of the steps above fail, Ivy will log why the config change failed and continue running the current config. The test suite should ensure that an upgrade will only happen when the local device is able to run Ivy with that new config file.

How to Supply the Source Code

The source code has to be hosted in a Git repository (can be public or private). We currently support GitLab and GitHub.

The config object has a field updater (see API reference), which defines from where the updater will pull new source code. If the version you want to run on is 1.2.3, please tag a commit with v1.2.3 (with a v prefix) in your repository - you do not have to create a GitHub/GitLab release; just tag the commit.

There is a test case at tests/integration/test_connection_to_repository.py that tests, whether the connection to the configured repository works.