Exact method of testing this is somewhat up to the implementer to decide what is easiest, but which still provides good enough coverage. These are my suggestions:
- Treat the Gitlab "dind" container as the "device", since we can do Docker operations there.
- For local testing, probably it is needed to execute the test inside a local dind container which can do Docker operations
- One of the tests handles rootfs support, which will be missing, but all we need is the entry in mender.conf, so this can be faked.
- Use mender-test-containers for more comprehensive testing.
- Acceptance tests created for Update Module in MEN-3839, using a semi-real device.
- Must test at least:
- Successful update from nothing = containers running afterwards.
- Unsuccessful update from nothing = nothing running afterwards.
- Successful update from previous containers = containers run afterwards, and none of the old ones do.
- It's a good idea to have one container less in the new docker-compose file, to make sure that the old one being obsoleted is not being orphaned.
- Unsuccessful update from previous containers = rollback works, and the old containers run afterwards, none of the new ones.
- After successful update, check that old digest is not available in docker images --digest anymore.
- Everything passing in Gitlab