Re: CI container image interference between staging and staging-7.2

[Michael Tokarev]

13.09.2023 02:07, Stefan Hajnoczi wrote:
> Hi,
> TL;DR Michael: Please check that the staging-7.2 branch has Dan's
> commit e28112d00703abd136e2411d23931f4f891c9244 ("gitlab: stable
> staging branches publish containers in a separate tag").
...

Mea cupla, Stefan.  I'm always forgetting about the fact that ci controls
don't work on older branches in one way or another. Sigh.

The patch(es) you're talking about - I didn't pick them up for 7.2 (which
was the branch in question this time, which interfered with your testing),
thinking it would be ok.  Yes, after this fiasco (which is the first one
actually), it looks like I should re-consider doing this.

It needs quite a few changes in there. And one of them is to actually
look at QEMU_CI={0,1,2} variable when pushing staging-N.M branches.  Right
now - and this is what I forgot this time once again, - I used QEMU_CI=1
so the job does not auto-start, but forgot that in 7.2 it auto-starts
regardless of QEMU_CI value.

I don't push staging-N.M branches often, usually doing all the CI on
a my gitlab repository instead. And when I do push to qemu-project,
I either intend to skip automatic job run, to run just the tests I'm
interested in, or push it at a time when no other pipelines are to be
run (which is easy due to time zone differences).

But actually I'm a bit surprised this issue happened to begin with.
Maybe something else is missing still.  The thing is that after
Daniel's changes, qemu/staging container tags should be named differently,
no?   Ah. No. Staging didn't change, it was staging-N.M which were
renamed.  Once again, I'm sorry for not thinking well enough about this, -
after container tags renaming I was kinda sure main staging tags were
different from old staging-N.M, which is not the case..

Please excuse me for this trouble.  Things like these usually takes quite
some time to figure out.. :(  I'll make sure this wont happen again,
one way or another.

Thank!

/mjt