On Fri, Jan 19, 2024 at 10:04:56AM -0300, Fabiano Rosas wrote: > Peter Xu <pet...@redhat.com> writes: > > > On Thu, Jan 18, 2024 at 01:49:51PM -0300, Fabiano Rosas wrote: > >> Until 9.0 is out, we need to keep the aarch64 job disabled because the > >> tests always use the n-1 version of migration-test. That happens to be > >> broken for aarch64 in 8.2. Once 9.0 is out, it will become the n-1 > >> version and it will bring the fixed tests. > >> > >> We can revert this patch when 9.0 releases. > >> > >> Signed-off-by: Fabiano Rosas <faro...@suse.de> > >> --- > >> .gitlab-ci.d/buildtest.yml | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml > >> index f0b0edc634..b344a4685f 100644 > >> --- a/.gitlab-ci.d/buildtest.yml > >> +++ b/.gitlab-ci.d/buildtest.yml > >> @@ -217,10 +217,14 @@ build-previous-qemu: > >> - QTEST_QEMU_BINARY_DST=./qemu-system-${TARGET} > >> QTEST_QEMU_BINARY=../build/qemu-system-${TARGET} > >> ./tests/qtest/migration-test > >> > >> +# This job is disabled until we release 9.0. The existing > >> +# migration-test in 8.2 is broken on aarch64. The fix was already > >> +# commited, but it will only take effect once 9.0 is out. > >> migration-compat-aarch64: > >> extends: .migration-compat-common > >> variables: > >> TARGET: aarch64 > >> + QEMU_JOB_OPTIONAL: 1 > > > > Optionally you can move the whole migration-compat-aarch64 from previous > > patch to here, then even if someone kicks off CI for previous commit it > > won't fail. > > I want to avoid having to think about this when 9.0 is out. This way > it'll be just a revert of this patch.
That's ok. > > > > > Would QEMU_JOB_SKIPPED suits more here? > > > > https://www.qemu.org/docs/master/devel/ci.html > > > > QEMU_JOB_OPTIONAL > > > > The job is expected to be successful in general, but is not run by > > default due to need to conserve limited CI resources. It is > > available to be started manually by the contributor in the CI > > pipelines UI. > > > > QEMU_JOB_SKIPPED > > > > The job is not reliably successsful in general, so is not currently > > suitable to be run by default. Ideally this should be a temporary > > marker until the problems can be addressed, or the job permanently > > removed. > > > > I suppose they all fall into "manual trigger" as a result, but just in case > > it'll behave differently in the future. > > > Ok, we can use SKIPPED. No need to repost then; if this is the only thing to change I can do it when queuing. Will wait a bit more for comment on patch 2. -- Peter Xu