Details
-
Type:
Task
-
Status: Open
-
Priority:
(None)
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: docker-compose support, docker-compose: Update Module
-
Labels:
-
Story Points:21
-
Epic Link:
-
Backlog:yes
-
Days in progress:0
Description
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 criteria:
- 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
Attachments
Issue Links
- is blocked by
-
MEN-3836 docker-compose Update Module repository
-
- Open
-