On Thu, Nov 03, 2022 at 12:25:49PM -0400, Stefan Hajnoczi wrote: > On Thu, 3 Nov 2022 at 11:59, Daniel P. Berrangé <[email protected]> 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. Grabbing the container URL from line 8 of the build log is my standard goto approach. > 2. The GitLab output does not contain the full command lines because > environment variables are hidden (e.g. $QEMU_CONFIGURE_OPTS). Note, $QEMU_CONFIGURE_OPTS is set by the container image itself, so there's no need to know that one. $CONFIGURE_ARGS meanwhile is set in the build-XXXXX template and easy to find. > 3. The .gitlab-ci.d/ is non-trivial (uses YAML templates and who knows > what else GitLab CI does when running the YAML). You shouldn't need to understand that to reproduce problems. At most just need to find the $CONFIGURE_ARGS and $MAKE_CHECK_ARGS settings for the build-XXX job at hand. > 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. Running the containers directly in docker/podman is how I reproduce pretty much everything locally, and its been pretty straightforward IME. 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 :|
