On 31/10/2024 11:05 pm, Stefano Stabellini wrote: > On Thu, 31 Oct 2024, Andrew Cooper wrote: >> On 31/10/2024 10:46 pm, Stefano Stabellini wrote: >>> On Thu, 31 Oct 2024, Andrew Cooper wrote: >>>> The Argo work already moved this artefact into the new form. Reuse that, >>>> and >>>> drop one test job. >>>> >>>> Signed-off-by: Andrew Cooper <[email protected]> >>> This is good but should we also remove >>> automation/tests-artifacts/alpine/3.18.dockerfile since we are at it? >> Well, that's another thing that needs careful consideration. >> >> That dockerfile needs updating in tandem with the build container (or >> lib$FOO.so's don't work when running the test), and it's hard enough to >> keep track of things when they're all in one repo. > Uhm, you have a good point. Two things come to mind. First, for this > patch: > > Reviewed-by: Stefano Stabellini <[email protected]>
Thanks. > Second, I think maybe it would be better for test-artifacts to use the > build containers from xen.git/automation/build ? So that at least all > build containers come from the same place? > > For instance, we would have to add any missing dependencies to > automation/build/alpine/3.18.dockerfile, from the list currently in > images/alpine/x86_64-build.dockerfile. Only a couple of things are > missing. Then remove images/alpine/x86_64-build.dockerfile, and use > registry.gitlab.com/xen-project/xen/alpine:3.18 in the test-artifacts > build jobs? First, I think it is important that hw/t-a uses main Xen's containers, rather than its own. That way, all the dockerfiles are in one place. As for merging the build and test-artefact dockerfile, I'm not so sure. They're almost completely dissimilar, and (amongst other things) we don't want to be including two full toolchains in the test initrd. So, I think they do need to remain separate, but the build/test-artefact split is weird already because build/ is both build and some test, but not all. I think things would benefit from relaying out automation/ somewhat. ~Andrew
