On Mon, 2020-06-08 at 17:41 +0100, Daniel P. Berrangé wrote: > On Mon, Jun 08, 2020 at 05:42:32PM +0200, Andrea Bolognani wrote: > > +.cirrus_build_default_job_template: &cirrus_build_default_job_definition > > + stage: native_build > > + image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master > > + script: > > + - | > > + if test -z "$CIRRUS_GITHUB_REPO" || test -z "$CIRRUS_API_TOKEN"; then > > + echo "WARN: Cirrus CI integration not set up correctly for your account" > > + echo "WARN: This job will be skipped" > > + echo "WARN: See ci/README.rst for more information" > > + exit 0 > > + fi > > This will give a misleading impression that the macOS / FreeBSD > job has been run for a user's merge request. Instead we shoudl > do > > > + - cirrus-run ci/cirrus/$NAME.yml.j2 > > only: > variables: > - $CIRRUS_GITHUB_REPO > - $CIRRUS_API_TOKEN > > this ensures the job is not even created if the contributor has not > configured things. Thus we can see from the list of jobs whether > the merge request has CI coverage of macOS/FreeBSD, instead of > having to read the job log to spot the warning. That's a great approach! I wanted to find a way to signal that more clearly, and I thought I could mark them as orange by exiting with a special return code, but apparently that's something that GitLab has not implemented despite being requested multiple times... Your solution gives us almost the same result with tools that we can actually use today :) > > +freebsd_11_task: > > + install_script: > > + - pkg install -y > > + augeas > > + autoconf > > + automake [...] > > For the dockerfiles, we're auto-generating using lcitool. > > IIUC, we should have sufficient info avialable in lcitol that > we can wrote a command to generate this entire file, including > the build_script commands. > > In fact eventually we could try to get to a point where we > auto-generate the .gitlab-ci.yml from lcitool. I mention this in the commit message. The goal is absolutely to generate these files using lcitool, I just haven't invested time into doing that yet because I wanted to make sure the overall approach was considered acceptable first. > > +macos_1015_task: > > + install_script: > > + - brew install > > + autoconf > > + automake > > + ccache [...] > > Obviously we'd need to define a mapping for macOS in lcitool > for this. Obviously :) -- Andrea Bolognani / Red Hat / Virtualization
