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

[Stefan Hajnoczi]

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).
2. The GitLab output does not contain the full command lines because
environment variables are hidden (e.g. $QEMU_CONFIGURE_OPTS).
3. The .gitlab-ci.d/ is non-trivial (uses YAML templates and who knows
what else GitLab CI does when running the YAML).

When doing what you suggested, how easy is it and how confident are
you that you're reproducing the same environment? Unless I missed
something it doesn't work very well.

Stefan