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@redhat.com>
---
 ci/integration.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ci/integration.yml b/ci/integration.yml
index 8b66a8c688..c234696d10 100644
--- a/ci/integration.yml
+++ b/ci/integration.yml
@@ -132,7 +132,7 @@ fedora-38-tests-local-env:
 
 fedora-38-upstream-qemu-tests-prebuilt-env:
   extends:
-    - .integration_tests_prebuilt_env
+    - .integration_tests_upstream_qemu_prebuilt_env
     - .fedora-38-upstream-qemu-tests
   needs:
     - x86_64-fedora-38-prebuilt-env
@@ -147,7 +147,7 @@ fedora-38-upstream-qemu-tests-prebuilt-env:
 
 fedora-38-upstream-qemu-tests-local-env:
   extends:
-    - .integration_tests_local_env
+    - .integration_tests_upstream_qemu_local_env
     - .fedora-38-upstream-qemu-tests
   needs:
     - x86_64-fedora-38-local-env
-- 
2.43.0
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

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

Reviewed-by: Peter Krempa <pkrempa@redhat.com>
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

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

-- 
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

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@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!

-- 
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

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@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 :|
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org