Re: [libvirt PATCH 1/2] ci: Enable Cirrus CI integration

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

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux