On 25/11/2025 05.00, John Snow wrote:
Some tests need test dependencies, some tests don't. Instead of running
"make check" manually, use a CI variable for the template that allows us
to front-load the testing dependencies without needing to incur another
re-configure command.
Signed-off-by: John Snow <[email protected]>
---
.gitlab-ci.d/buildtest-template.yml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/.gitlab-ci.d/buildtest-template.yml
b/.gitlab-ci.d/buildtest-template.yml
index d866cb12bb1..cfa123d3a10 100644
--- a/.gitlab-ci.d/buildtest-template.yml
+++ b/.gitlab-ci.d/buildtest-template.yml
@@ -32,6 +32,10 @@
then
pyvenv/bin/meson configure . -Dbackend_max_links="$LD_JOBS" ;
fi || exit 1;
+ - if test -n "$SETUP_CHECK_VENV";
+ then
+ make check-venv;
+ fi;
I'm not sure, but I think this is likely not quite working as you intended
it. The above code hunk is added to native_build_job_template, i.e. it's
executed for the build-* jobs, but in the next patch, you only set the
environment variable on the crash-test-* jobs. I don't think that the
environment variables propagate backward from a later job to an earlier one.
Looking at the output of another build job, e.g. build-system-alpine:
https://gitlab.com/thuth/qemu/-/jobs/12211712932#L2156
... it looks like pygdbmi is now also always installed there, i.e. something
else triggers "check-venv" on all build jobs now, and that's why you were
able to drop the "check-venv" in the crash-test-* jobs in the next patch
now. No clue what's causing this now, but IMHO it should be fine if we just
unconditionally do "check-venv" in all build jobs anyway (we also need the
venv in a bunch of other test jobs anyway), so I'd rather do the "make
check-venv" in this patch unconditionally here, and drop the next patch that
sets SETUP_CHECK_VENV in the crash-test jobs. WDYT?
Thomas
