On Wed, Apr 23, 2025 at 02:01:58PM -0300, Fabiano Rosas wrote: > Stefan Hajnoczi <stefa...@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
