On Fri, Mar 20, 2020 at 02:59:36PM +0000, Daniel P. Berrangé wrote:
On Fri, Mar 20, 2020 at 03:52:15PM +0100, Erik Skultety wrote:
> On Tue, Mar 10, 2020 at 10:09:44AM +0000, Daniel P. Berrangé wrote:
> > With GitLab CI aiming to replace Jenkins and Travis for CI purposes, we
> > need to expand the coverage to include native builds. This patch adds
> > all the jobs currently run in Travis. Compared to Jenkins we obviously
> > miss the FreeBSD jobs, but also Debian 10 and Fedora 30, but we gain the
> > Ubuntu 1804 job as a substitute for Debian.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> > ---
> > .gitlab-ci.yml | 41 +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index e28ec584ea..3e15d08d17 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -1,7 +1,39 @@
> > stages:
> > - website
> > + - native_build
> > - cross_build
> >
> > +
> > +.native_build_job_template: &native_build_job_definition
> > + stage: native_build
> > + script:
> > + - mkdir build
> > + - cd build
> > + - ../autogen.sh $CONFIGURE_OPTS || (cat config.log && exit 1)
> > + - make -j $(getconf _NPROCESSORS_ONLN) syntax-check
> > + - make -j $(getconf _NPROCESSORS_ONLN) distcheck
>
> I think ^this should more closely follow what we have in the lcitool playbooks,
> e.g. start with:
> - rm -rf build
The source tree is already pristine because this is always executed in
a fresh container environment, so there's nothing that will need deleting.
Right, but my point was that if e.g. we introduce a FreeBSD builder, we'd want
to reference the same job template in which case the directory will exist.
> Also, since I've been playing with migrating other machines to PSI for a while,
> 'make' should be replaced with $MAKE otherwise native_build job reference
won't
> work on FreeBSD.
I'll need to check if $MAKE is actually set or not.
Huh, it's actually not...we need to fix that, but that is a patch for another
day.
> Maybe even do make install to VIRT_PREFIX?
'distcheck' does an install step. There's no shared install tree between
jobs, so the VIRT_PREFIX concept isn't applicable.
Oh, didn't realize that.
> Otherwise looks good to me.
> Reviewed-by: Erik Skultety <skultety.erik(a)gmail.com>
Damn, this should have been:
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>
#combinedworkingenvironment