Re: [PATCH v2 1/6] Add a QTB container to run the Xen riscv64 tests

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Thu, Oct 22, 2026 at 03:28:26PM +0200, Oleksii Kurochko wrote:
> On 8/27/26 11:42 AM, Baptiste Le Duc wrote:
> > ---
> >   containerize                            |  1 +
> >   images/debian/13-qtb-riscv64.dockerfile | 45 +++++++++++++++++++++++++
> 
> This is more a question for the CI maintainers: should this container
> live in test-artifacts at all?
> 
> So far test-artifacts only holds containers for building its own
> artifacts (kernels, rootfs, microcode), which xen.git then pulls in via
> cross-project needs:. The containers the xen.git test jobs run in,
> including debian:13-riscv64, which already carries
> qemu-system-riscv64 for the test phase, and the hardware runner ones,
> are all built from automation/build/ in xen.git and pulled from
> XEN_REGISTRY.
> 
> Having it as automation/build/debian/13-qtb-riscv64.dockerfile in
> xen.git would keep the container next to its only user, avoid the new
> ARTIFACTS_REGISTRY variable and the image: override in patch 6, and
> drop the "must land first" ordering between two repositories.

Indeed, the new container would fit better in the `xen.git` tree.

And can you rename the container? I think the format is
"$distrib/$release-$arch-$comments"

I guess $arch here should be "x86_64", with the comment saying
"qtb-riscv64".

> > diff --git a/images/debian/13-qtb-riscv64.dockerfile 
> > b/images/debian/13-qtb-riscv64.dockerfile
> > new file mode 100644
> > index 0000000..86215d3
> > --- /dev/null
> > +++ b/images/debian/13-qtb-riscv64.dockerfile
> > @@ -0,0 +1,45 @@
> > +# syntax=docker/dockerfile:1
> > +FROM --platform=linux/amd64 debian:trixie-slim
> > +LABEL maintainer.name="The Xen Project"
> > +LABEL maintainer.email="xen-devel@xxxxxxxxxxxxxxxxxxxx"
> > +
> > +ENV DEBIAN_FRONTEND=noninteractive
> > +
> > +ARG QEMU_REPO=https://gitlab.com/xen-project/people/amd/qemu.git
> > +ARG QEMU_COMMIT=24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab
> > +
> 
> This commit is currently the tip of the 'safety' branch, and no tag
> points to it. If that branch gets rebased, the commit may become
> unreachable and the container will no longer rebuild. Could a tag be
> created for it in the fork?

I would rather keep the commit hash, but adding a comment that it's
the `safety` branch would be useful.

Having the container fails to build because the commit disappear is
better I think than having the test failed because the branch have
changed the way qtb is implemented.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech