tests: make the answers/bridge.yaml less fragile#2326
tests: make the answers/bridge.yaml less fragile#2326dbungert wants to merge 1 commit intocanonical:mainfrom
Conversation
ogayot
left a comment
ogayot
left a comment
There was a problem hiding this comment.
I think we can improve the environment handling but the overall idea looks good to me, thanks!
scripts/runtests.sh
Outdated
| catalog=examples/sources/install.yaml | ||
| fi | ||
| if [ -n "$environ" ]; then | ||
| source "$environ" |
There was a problem hiding this comment.
I think it would be better to run that and the subiquity command in a subshell. This way we don't clutter the environment and don't need to clean it up afterwards.
If it makes it easier, we can move the whole body of this for loop to a function and run that function in a subshell.
Hopefully this doesn't break everything else?
for answers in examples/answers/*.yaml; do
# Run in a subshell
(handle_answers "$answers")There was a problem hiding this comment.
Alternatively, TIL about dotenv (apt install python3-dotenv-cli) which can do something like:
dotenv -e "$environ" ls -l
The format of the env file is KEY=value (no export)
Note that there seems to exist different implementations of the dotenv CLI, taking different options.
There was a problem hiding this comment.
My updated proposal uses the env tool to similar result.
While debugging an integration test failure on canonical#2325 that was at root cause a failure to run lsb_release() with a dry-run value, I found the following for the examples/answers/bridge.yaml test: * this test wants to "run" Ubuntu drivers, and use that result to cause the bridge kernel to be installed * the default "has-drivers" dry-run interface lists both drivers and an OEM kernel metapackage * pre-resolute, this metapackage didn't matter because we're running on server and ignored it entirely * with PR 2325, when using the resolute OEM metapackage behavior on server, the metapackage was considered, so the OEM metapackage won out over bridge kernel, which is desired behavior for the OEM-vs-bridge interaction but fails the answers/bridge.yaml test case Add an environ capability to the integration tests, to set a desired SUBIQUITY_DEBUG value, and give ubuntu_drivers.py a new style of "yes-drivers-no-oem" which does what it sounds like. This means that independent of considering OEM metapackages or not, this test case will run drivers, have drivers, use that to trigger bridge kernel behavior, and that bridge kernel won't be overwritten by a OEM kernel.
dbungert
force-pushed
the
fix-bridge-integration
branch
from
f02a79b to
a298b0a
Compare
| environ="${1:-/dev/null}" | ||
| shift | ||
|
|
||
| env $(< $environ) LANG=C.UTF-8 "$@" |
There was a problem hiding this comment.
I think this is going to preserve the double quotes you have in your env file - but it's only fine to remove them if there's no whitespaces.
You could do "$(< $environ)" instead of $(< environ), but it's not going to work if there's multiple variables defined in the env file.
Sourcing the file is probably easier ...
3 participants
While debugging an integration test failure on
#2325 that was at root cause a failure to run lsb_release() with a dry-run value, I found the following for the examples/answers/bridge.yaml test:
Add an environ capability to the integration tests, to set a desired SUBIQUITY_DEBUG value, and give ubuntu_drivers.py a new style of "yes-drivers-no-oem" which does what it sounds like. This means that independent of considering OEM metapackages or not, this test case will run drivers, have drivers, use that to trigger bridge kernel behavior, and that bridge kernel won't be overwritten by a OEM kernel.