qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v2 00/82] pci,pc,virtio: features, tests, fixes, cleanups


From: Daniel P . Berrangé
Subject: Re: [PULL v2 00/82] pci,pc,virtio: features, tests, fixes, cleanups
Date: Thu, 3 Nov 2022 16:47:36 +0000
User-agent: Mutt/2.2.7 (2022-08-07)

On Thu, Nov 03, 2022 at 04:38:35PM +0000, Daniel P. Berrangé wrote:
> On Thu, Nov 03, 2022 at 12:25:49PM -0400, Stefan Hajnoczi wrote:
> > On Thu, 3 Nov 2022 at 11:59, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Thu, Nov 03, 2022 at 11:49:21AM -0400, Stefan Hajnoczi wrote:
> > > > gitlab-runner can run locally with minimal setup:
> > > > https://bagong.gitlab.io/posts/run-gitlab-ci-locally/
> > > >
> > > > I haven't tried it yet, but that seems like the most reliable (and
> > > > easiest) way to reproduce the CI environment.
> > >
> > > IMHO that is total overkill.
> > >
> > > Just running the containers directly is what I'd recommend for any
> > > attempt to reproduce problems. There isn't actually anything gitlab
> > > specific in our CI environment, gitlab merely provides the harness
> > > for invoking jobs. This is good as it means we can move our CI to
> > > another systems if we find Gitlab no longer meets our needs, and
> > > our actual build env won't change, as it'll be the same containers
> > > still.
> > >
> > > I wouldn't recommend QEMU contributors to tie their local workflow
> > > into the use of gitlab-runner, when they can avoid that dependency.
> > 
> > If there was a complete list of commands to run I would agree with
> > you. Unfortunately there is no easy way to run the container locally:
> > 1. The container image path is hidden in the GitLab output and easy to
> > get wrong (see Ani's reply).
> 
> That is bizarre
> 
>    Pulling docker image 
> registry.gitlab.com/qemu-project/[MASKED]/fedora:latest ...
> 
> I've not seen any other gitlab project where the paths are 'MASKED' in
> this way. Makes me wonder if there's some setting in the QEMU gitlab
> project causing this, as its certainly not expected behaviour.

Spoke with Peter on IRC, and we had a variable set CIRRUS_GITHUB_REPO
with value 'qemu/qemu' that was marked as 'masked'. This caused gitlab
to scrub that string from the build logs.  We've unmasked that now,
so the container URLs should be intact from the next CI pipeline
onwards.  Masking is only needed for security sensitive variables
like tokens, passwords, etc

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]