Migration compatibility test broken on major version releases

Migration compatibility test broken on major version releases

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

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

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.

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).

Thanks!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Migration compatibility test broken on major version releases

[Fabiano Rosas]

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!

>
> Thanks!
>
> Stefan

Re: Migration compatibility test broken on major version releases

[Peter Xu]

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