1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
summary: verify a simple UC18+ remodel
details: |
Execute a simple remodel scenario under the test-snapd brand. Both
models use the same test-snapd-from device view store. The new model
requires additional snaps that are present in the test-snapd-from
store.
systems: [ubuntu-18.04-64, ubuntu-2*]
environment:
NESTED_CUSTOM_AUTO_IMPORT_ASSERTION: $TESTSLIB/assertions/test-snapd-remodel-auto-import.assert
NESTED_ENABLE_TPM: false
NESTED_ENABLE_SECURE_BOOT: false
NESTED_USE_CLOUD_INIT: false
NESTED_REPACK_KERNEL_SNAP: false
NESTED_REPACK_GADGET_SNAP: false
NESTED_REPACK_BASE_SNAP: false
SNAPD_TEST_BRAND: test-snapd
# store we are remodeling from
SNAPD_STORE_FROM: CQvkdMjgbapk821Po2cF
# device serial, this should match the sub-store mapping rules in the serial
# vault
SERIAL: 1234-snapd-remodel-testing
OFFLINE_REMODEL: false
OFFLINE_REMODEL/offline: true
prepare: |
variant="$(tests.nested show version)"
# TODO: once the gadget snap is published, this will download it from the
# store
cp -av "$TESTSLIB/snaps/test-snapd-remodel-pc-$variant" test-snapd-remodel-pc
test -n "$SERIAL"
echo "$SERIAL" > test-snapd-remodel-pc/serial
snap pack test-snapd-remodel-pc
REMODEL_SNAP=$(ls test-snapd-remodel-pc_*.snap)
mv "$REMODEL_SNAP" "$(tests.nested get extra-snaps-path)"
# Use UBUNTU_STORE_AUTH_DATA_FILENAME en var to authenticate against the store
# with the remodel-store-viewer user. The file authentication is generated by using
# snapcraft 6.x and running the command 'snapcraft export-login <filename>'
# Every 12 months (in January) the auth file needs to be regenerated.
export UBUNTU_STORE_AUTH_DATA_FILENAME="$TESTSLIB/remodel-store-viewer.auth"
export NESTED_CUSTOM_MODEL="$TESTSLIB/assertions/test-snapd-remodel-pc-$variant.model"
tests.nested build-image core
tests.nested create-vm core
execute: |
variant="$(tests.nested show version)"
boot_id="$(tests.nested boot-id)"
# wait until device is initialized and has a serial
remote.wait-for device-initialized
remote.exec "snap model --assertion" | MATCH "brand-id: $SNAPD_TEST_BRAND\$"
remote.exec "snap model --assertion" | MATCH "store: $SNAPD_STORE_FROM\$"
remote.exec "snap model --assertion" | MATCH '^model: test-snapd-remodel-pc$'
remote.exec "snap model --assertion --serial" | MATCH "serial: ${SERIAL}\$"
# the new model requires hello-world snap to be present, make sure that the
# snap and its dependency core aren't installed yet
not remote.exec "snap list hello-world"
not remote.exec "snap list core"
# snapd gets stuck ensuring prerequisites of hello-world, which is the
# installation of core, workaround this problem by installing core
# explicitly
# TODO: drop this once prereq is fixed
remote.exec "snap install core"
remote.push "$TESTSLIB/assertions/test-snapd-remodel-pc-just-model-$variant.model"
remodel_options="--no-wait"
if [ "$OFFLINE_REMODEL" = true ]; then
remote.exec "snap download --basename=hello-world hello-world"
remote.exec "snap download --basename=core core"
# We need coreXX and pc-kernel too as the active track on the device is
# {latest,XX}/edge while the model assertion requires
# {latest,XX}/stable. Therefore a track change is detected. Note that
# snapd and the gadget are on local revisions (x1).
base=core$variant
remote.exec "snap download --basename=$base $base"
remote.exec "snap download --basename=pc-kernel --channel=$variant/stable pc-kernel"
# TODO provide serial assertion so no connection is needed
remodel_options="$remodel_options --snap hello-world.snap --assertion hello-world.assert \
--snap core.snap --assertion core.assert \
--snap $base.snap --assertion $base.assert \
--snap pc-kernel.snap --assertion pc-kernel.assert"
fi
if ! CHANGE_ID=$(remote.exec "sudo snap remodel $remodel_options \
test-snapd-remodel-pc-just-model-$variant.model" 2> error.log); then
if [ "$OFFLINE_REMODEL" = true ]; then
# We cannot change offline the model yet, check the error and
# consider successful the test for the moment.
# TODO as a first step we need to provide the new serial assertion from a file
MATCH "cannot remodel offline to different brand ID / model yet" < error.log
exit 0
fi
printf "Error while running snap remodel command\n"
exit 1
fi
test -n "$CHANGE_ID"
# very long retry wait for the change to be in stable state, where stable
# means that it's done or failed in which case we fail the test on the next
# check just below
retry -n 100 --wait 5 sh -c "remote.exec sudo snap changes |
MATCH '^${CHANGE_ID}\s+(Done|Undone|Error)'"
# check that the change was successful
remote.exec "sudo snap changes" | MATCH "^${CHANGE_ID}\s+Done"
current_boot_id="$( tests.nested boot-id )"
if [ "$variant" = "20" ] || [ "$variant" = "22" ]; then
# we should have rebooted a couple of times (at least twice for the recovery
# system and the base), so boot-id should be different
test "$boot_id" != "$current_boot_id"
else
# but there is no reboot on UC18
test "$boot_id" == "$current_boot_id"
fi
# we are remodeling within the same brand and store
remote.exec "snap model --assertion" | MATCH "brand-id: $SNAPD_TEST_BRAND\$"
remote.exec "snap model --assertion" | MATCH "store: $SNAPD_STORE_FROM\$"
# new model
remote.exec "snap model --assertion" | MATCH '^model: test-snapd-remodel-pc-just-model$'
# but the same serial
remote.exec "snap model --assertion --serial" | MATCH "serial: ${SERIAL}\$"
# both new snaps are installed now
remote.exec "snap list hello-world"
remote.exec "snap list core"
# and it's possible to run hello-world
remote.exec "hello-world" | MATCH 'Hello World!'
|
