Repository navigation
spread configuration of tests template uses unsupported config #264
Description
sdkcraft/sdkcraft/templates/simple/tests/spread.yaml.j2
Lines 5 to 10 in 3573cf0
I'm not sure vm: true is supported in official spread. It seems inspired by canonical/spread#286 or canonical/spread#185 but it's unclear to me where it comes from.
FWIW, I'm not sure it's related but spread -v on this configuration fails to connect to the container:
$ ~/go/bin/spread -v
2026-07-21 13:58:35 Found /home/ubuntu/Projects/Canonical/Developer Success/mlflow-sdk/tests/spread.yaml.
2026-07-21 13:58:35 Project content is packed for delivery (0.56KB).
2026-07-21 13:58:35 Sequence of jobs produced with -seed=1784635115
2026-07-21 13:58:35 If killed, discard servers with: spread -reuse-pid=503100 -discard
2026-07-21 13:58:35 Allocating lxd:ubuntu-26.04...
2026-07-21 13:58:36 Cannot find cached LXD image for lxd:ubuntu-26.04.
2026-07-21 13:58:39 Waiting for lxd container spread-77-ubuntu-26-04 to have an address...
2026-07-21 13:58:41 Allocated lxd:ubuntu-26.04 (spread-77-ubuntu-26-04).
2026-07-21 13:58:41 Connecting to lxd:ubuntu-26.04 (spread-77-ubuntu-26-04)...
2026-07-21 13:59:54 Discarding lxd:ubuntu-26.04 (spread-77-ubuntu-26-04), cannot connect: cannot connect to lxd:ubuntu-26.04 (spread-77-ubuntu-26-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain
2026-07-21 13:59:55 Successful tasks: 0
2026-07-21 13:59:55 Aborted tasks: 2
error: unsuccessful run
Activity
jonathan-conder commentedon Jul 21, 2026
It's not a bug. We use a fork of spread but eventually we'll upstream our changes into the main one or spread-plus. Our fork currently uses VMs by default, but the config puts
vm: trueso that tests don't break when we eventually migrate off the fork.Or maybe we'll start using workshop VMs as the backend.
I'll leave open for now as a reminder that we should do the upstreaming work at some point
jonathan-conder commentedon Jul 22, 2026
I think even after we upstream our changes, we'll still patch spread so it logs in as a normal user instead of
root. Also, we do some additional setup e.g. installing Workshop. So running spread directly will probably never be supported. Is there a reason you want to do it that way instead of usingsdkcraft test?astrojuanlu commentedon Jul 22, 2026
Muscle memory and not having to wait for the
sdkcraft packto begin the test.Other *craft tools also do this thing of forcing you to pack before test and I've been running spread manually as a result.
That would be unfortunate, I think it would be nice to be able to run spread or spread-plus directly.
jonathan-conder commentedon Jul 22, 2026
How about we add a
--skip-packflag or something then?jonathan-conder commentedon Jul 22, 2026
Although if you skip the packing there will be no SDK inside the VM to test... After the initial pack, how long do subsequent ones take?
astrojuanlu commentedon Jul 22, 2026
Yeah this would be ideal, but after digging a bit more, I think that's not the direction we're taking canonical/craft-application#800
I could find creative ways to work around that in spread 😄
23 seconds for doing nothing ("already packed" * 2), about 4 minutes if anything in the source directory changes. Probably I'm doing something silly https://github.com/astrojuanlu/mlflow-sdk/blob/7faf404/sdkcraft.yaml feedback welcome.
jonathan-conder commentedon Jul 22, 2026
We don't have to follow what upstream is doing; but I've followed that issue. If they fix it will save us some effort.
If you don't mind being really hacky about it, during the first pack + spread run there should be a subdirectory of the project named
.craft-spread-*; you can make a copy of it and run our spread fork (see snapcraft.yaml for the repo and commit hash) from that directory.I'll take a look and see if we can speed this up
jonathan-conder commentedon Jul 22, 2026
Can confirm about 20s to "pack" even if the build instances are already running, seems to take 2-3s too long to figure that out. I can dig into this further when I get a chance.
Also build-snaps appears for a while in the logs, I wonder if you can speed things up by installing
uvandnodein a different way?astrojuanlu commentedon Jul 23, 2026
Possibly, I'll see what I can do! But
uvgets installed by theuvplugin, at this point I'll probably have to use thenilone.