On Tue, Jan 09, 2024 at 01:02:38AM -0800, Andrea Bolognani wrote:
On Tue, Jan 09, 2024 at 12:41:25AM -0800, Andrea Bolognani wrote:
> On Mon, Jan 08, 2024 at 09:07:33PM +0100, Peter Krempa wrote:
> > On Mon, Jan 08, 2024 at 11:43:22 +0100, Andrea Bolognani wrote:
> > > These are jobs are supposed to be running tests using a QEMU
> > > binary built from the latest upstream sources, but right now
> > > they're just doing the same thing as the other jobs for the
> > > target. Use the correct job templates.
> > >
> > > Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
> > > ---
> > > ci/integration.yml | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Looks reasonable, but IMO the CI stuff got out of hand complexity wise,
> > so I'm not as confident in my review as usually.
>
> Yeah, I'm not too confident myself, and unlike regular CI jobs I
> thought there was no way to test changes to the integration part
> before pushing. I see now that the LIBVIRT_CI_INTEGRATION variable
> exists though, so I'll give that a try and see whether I can get a
> successful run out of it before pushing.
Never mind, the jobs got stuck because a suitable runner can't be
found. Can't say that I'm surprised, we don't want to give anyone
access to those scarce resources... Anyway, at least the jobs were
created according to my expectations, so that's good to know. I'm
going to push the series now. Thanks for the review!
If you create a pipeline in your fork, it would not be able to accesss
the runners, but if you create a merge request against upstream, it
would have access to the runners, since you're a project member.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|