Re: [libvirt PATCH 1/2] ci: Enable Cirrus CI integration
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