Re: Migration compatibility test broken on major version releases

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 23, 2025 at 02:01:58PM -0300, Fabiano Rosas wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
> 
> > Hi Fabiano,
> > The build-previous-qemu job does not work when a new major version is
> > released:
> > https://gitlab.com/qemu-project/qemu/-/jobs/9788294494
> >
> 
> You might be using a slightly different workflow from Peter and Richard,
> I don't think this ever happened before. But that's totally fine, I'll
> change the job to behave better in that case.
> 
> > The previous version computation produces "v10.0.0" when testing:
> >
> >   $ export QEMU_PREV_VERSION="$(sed 's/\([0-9.]*\)\.[0-9]*/v␁.0/' VERSION)"
> >   $ git remote add upstream https://gitlab.com/qemu-project/qemu
> >   $ git fetch upstream refs/tags/$QEMU_PREV_VERSION:refs/tags/$QEMU_PREV_VERSION
> >   warning: redirecting to https://gitlab.com/qemu-project/qemu.git/
> >   fatal: couldn't find remote ref refs/tags/v10.0.0
> >
> > The CI job runs before the v10.0.0 tag is pushed to the repo. (The tag
> > is only pushed once tests have passed.)
> >
> > Even if the tag was there and git fetch succeeded, the test would test
> > migration between v10.0.0 and v10.0.0, which doesn't seem to be the
> > purpose of the test.
> >
> 
> Yes, but since that one commit does not have any code anyway, we've
> decided to just let it run on the same version. The very next commit
> will be aligned again. Still, the time-of-tag issue was indeed an
> oversight.
> 
> > Please adjust the test to handle this situation. For now I will re-run
> > the job after pushing the final tag (since it already passed for the
> > release candidate tag).
> 
> Will do, thanks!

Just a quick thought - maybe we can add a rule (before the default rules in
the dependent job, so as to not get the last "when: always" trap it..) to
skip this job as long as the ending is .0 in VERSION.

Thanks,

-- 
Peter Xu