[U-Boot] [PATCH v2] travis: rework NXP layerscape jobs

[Tom Rini]

On Thu, Nov 21, 2019 at 07:24:26AM +0100, Heiko Schocher wrote:
> Hello Bin,
> 
> Am 21.11.2019 um 06:51 schrieb Bin Meng:
> > Hi Heiko,
> > 
> > On Thu, Nov 21, 2019 at 1:48 PM Heiko Schocher <hs at denx.de> wrote:
> > > 
> > > remove from NXP arm32 all layerscape boards and
> > > build them instead in already existing layerscape
> > > jobs (which now not only build aarch64 boards)
> > > 
> > > Signed-off-by: Heiko Schocher <hs at denx.de>
> > > ---
> > > travis build:
> > > https://travis-ci.org/hsdenx/u-boot-test/builds/614396275?utm_medium=notification&utm_source=email
> > > 
> > > Changes in v2:
> > > - collect in the layerscape jobs not only aarch64 based
> > >    boards as Tom suggested.
> > > - change subject, old was
> > >    "travis: split NXP ARM32 job"
> > > 
> > >   .travis.yml | 28 ++++++++++++++--------------
> > >   1 file changed, 14 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/.travis.yml b/.travis.yml
> > > index f6aec96770..d5f34f96cc 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -183,27 +183,27 @@ matrix:
> > >       - name: "buildman ARM bcm"
> > >         env:
> > >           - BUILDMAN="bcm -x mips"
> > > -    - name: "buildman NXP ARM32"
> > > +    - name: "buildman NXP ARM32 (catch-all)"
> > >         env:
> > > -        - BUILDMAN="freescale -x powerpc,m68k,aarch64"
> > > -    - name: "buildman NXP AArch64 LS101x"
> > > +        - BUILDMAN="freescale -x powerpc,m68k,aarch64,ls101,ls102,ls104,ls108,ls20,lx216"
> > > +    - name: "buildman NXP LS101x"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&ls101"
> > > -    - name: "buildman NXP AArch64 LS102x"
> > > +        - BUILDMAN="freescale&ls101"
> > > +    - name: "buildman NXP LS102x"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&ls102"
> > > -    - name: "buildman NXP AArch64 LS104x"
> > > +        - BUILDMAN="freescale&ls102"
> > > +    - name: "buildman NXP LS104x"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&ls104"
> > > -    - name: "buildman NXP AArch64 LS108x"
> > > +        - BUILDMAN="freescale&ls104"
> > > +    - name: "buildman NXP LS108x"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&ls108"
> > > -    - name: "buildman NXP AArch64 LS20xx"
> > > +        - BUILDMAN="freescale&ls108"
> > > +    - name: "buildman NXP LS20xx"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&ls20"
> > > -    - name: "buildman NXP AArch64 LX216x"
> > > +        - BUILDMAN="freescale&ls20"
> > > +    - name: "buildman NXP LX216x"
> > >         env:
> > > -        - BUILDMAN="freescale&aarch64&lx216"
> > > +        - BUILDMAN="freescale&lx216"
> > >       - name: "buildman i.MX6 tqc"
> > >         env:
> > >           - BUILDMAN="mx6&tqc"
> > 
> > Will you do the same for Azure? Or does this only apply to Travis?
> 
> The patch is only for travis, as travis has a job timeout of 50 minutes,
> and this job took to long for me...
> 
> The question is, does have Azure also such a job timeout?
> 
> Do we want to have the Azure jobs in sync with travis jobs?

So, we have a few things to consider here (and it goes for this patch
and the sun8i/oranagepi one too).  First, Travis times can be heavily
variable and I think that's what happened here.  I don't see these jobs
timing out usually but when they get put on a slow VM, they can.  That
said, working around that can result in a little cleaner separation in
the file, so it's worth dealing with.  Second, there's pros and cons to
trying to keep Travis and Azure splits in-sync.  Since it's not a 1:1
match in the split, as we can get more done per Azure job, it's more of
a guess work on when to keep things in sync (for more parallelization
and faster Azure jobs) or not.

So in this case, I think we should try and keep them in sync as it's
just changes to what we pass buildman (so easy enough to get right by
inspection) and might speed the overall task up slightly.  In the case
of the orangepi split, at this time I don't think it's worth doing to
Azure as well.  Excluding orangepi in a few places, but then spinning up
another job isn't going to be wall-clock win and might be a small loss,
and the limit within Azure is parallel jobs not build run time.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/cd6fbc71/attachment.sig>