Re: Please add new Android branches

Guillaume,

I guess we didn't get to a complete plan... From above, can we enable these:

1) compilers: gcc-10, clang-17
2) archs: arm, arm64, i386, x80_64, riscv
3) same configs as current android tests
4) plus configs used by corresponding stable kernel
(https://linux.kernelci.org/job/stable) not included in #3


On Mon, Sep 25, 2023 at 8:17 AM Todd Kjos <[email protected]> wrote:
>
> On Mon, Sep 25, 2023 at 1:22 AM Guillaume Tucker
> <[email protected]> wrote:
> >
> > On 20/09/2023 00:54, Todd Kjos wrote:
> > > Guillaume,
> > >
> > > How about this for android trees:
> > >
> > > 1) same compilers as current config (gcc-10, clang-14)
> > > 2) archs: arm, arm64, i386, x80_64, riscv
> > > 3) same configs as current android tests
> > > 4) plus configs used by corresponding stable kernel
> > > (https://linux.kernelci.org/job/stable) not included in #3
> >
> > OK thanks, I think we can set this up easily.  We'll get back to
> > you if there's any ambiguity.
> >
> > > We get a nice benefit from sync'ing with the stable kernels since it
> > > allows us to tell which issues originate upstream and which are
> > > introduced by android changes. It's also useful to build each with
> > > both toolchains so we can expose the cases where gcc-10 is OK but
> > > clang-14 has issues (and visa-versa).
> > >
> > > I don't think we need to build all of the combinations if there are
> > > too many builds - we could trim out some of the configs from #4 (you
> > > can recommend which).
> >
> > OK, we can look at past results or optimise incrementally over
> > the weeks to streamline the overall build coverage.
> >
> > > We'd also like to start in an all-green state. So let's trim out the
> > > error cases that aren't caused by android kernel code. I think there
> > > are some 32-bit cases that fail with the clang-14 tools and some other
> > > cases that fail in stable.
> > >
> > > Could we start with all of the builds for #1 - #4 and then tune it up
> > > after a few runs to get rid of long-failing cases and/or to just
> > > reduce the load on the build service?
> >
> > I believe this part of the discussion is still unresolved with
> > Nick, and maybe it would make more sense to address this when the
> > builds get moved to the new API where we'll have more flexibility
> > and more accurate log parsing etc.
> >
> > Another aspect that wasn't too clear in the discussions, should
> > it be clang-14 or a more recent version?  Right now, mainline
> > builds already include clang-11 (oldest supported one) and
> > clang-16 and linux-next builds use clang-17.  So there is
> > upstream build coverage for them, and if clang-14 is the standard
> > version for Android kernels then I guess it would make sense to
> > stick to it - but that's up to you.  Doing both clang-14 and
> > clang-17 for Android builds would seem overkill to me though.
>
> I'd be fine with tracking the latest stable clang version (clang-17
> now) and dropping clang-14 so we can help the clang team find
> regressions.
>
> >
> > Cheers,
> > Guillaume
> >
> > > On Wed, Sep 6, 2023 at 12:50 PM Todd Kjos <[email protected]> wrote:
> > >>
> > >> +Viktor Martensson +Betty Zhou
> > >>
> > >> Guillaume,
> > >>
> > >> I think that's a great idea. I'll get back to you with the set of
> > >> configs, arch, compilers we'd like to have coverage for.
> > >>
> > >> -Todd
> > >>
> > >>
> > >> On Wed, Sep 6, 2023 at 11:46 AM Guillaume Tucker
> > >> <[email protected]> wrote:
> > >>>
> > >>> Hi Todd,
> > >>>
> > >>> On 05/09/2023 19:18, Todd Kjos wrote:
> > >>>> On Thu, Aug 10, 2023 at 8:56 AM Todd Kjos <[email protected]> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Jul 11, 2023 at 4:57 AM Guillaume Tucker <[email protected]> wrote:
> > >>>>>>
> > >>>>>> Hi Todd,
> > >>>>>>
> > >>>>>> On 11/07/2023 00:41, Todd Kjos wrote:
> > >>>>>>> Please add the following new Android branches to kernelci testing.
> > >>>>>>>
> > >>>>>>> repo: https://android.googlesource.com/kernel/common
> > >>>>>>> branches:
> > >>>>>>> - android15-6.1
> > >>>>>>> - android14-6.1-lts
> > >>>>>>> - android14-5.15-lts
> > >>>>>>
> > >>>>>> I've created this PR accordingly:
> > >>>>>>
> > >>>>>>   https://github.com/kernelci/kernelci-core/pull/2002
> > >>>>>>
> > >>>>>> Please note that we're now operating with reduced build coverage
> > >>>>>> due to some temporary limitations with our Azure subscription.  I
> > >>>>>> know the Android kernel builds should be covered by the GCP
> > >>>>>> clusters but right now the system is designed to distribute
> > >>>>>> kernel builds randomly across all clusters so we can't easily tie
> > >>>>>> Android builds to the Android clusters.  Hopefully we'll find a
> > >>>>>> solution to go back to normal coverage within a week or two.
> > >>>>>
> > >>>>>
> > >>>>> Hi Guillaume, Any ETA for when the full set of builds is restored? We still have greatly reduced build coverage and it's been a month.
> > >>>>
> > >>>> Ping. We are getting a lot less value out of kernelci with the greatly
> > >>>> reduced set of builds for the Android kernels. When will the full
> > >>>> build coverage be resumed?
> > >>>>
> > >>>> If it needs to stay reduced, can we decide precisely which builds are
> > >>>> done for Android kernels?
> > >>>
> > >>> Sorry for the slow reply.
> > >>>
> > >>> I think it's fine now to re-enable the Android builds and maybe
> > >>> we should also take this opportunity to confirm which ones are
> > >>> the most relevant to you guys.  As part of the process of
> > >>> adjusting the build coverage, I also fixed the GKI builds which I
> > >>> thought were the main ones.  Even if there is enough build
> > >>> capacity to build "everything", keeping it streamlined to what is
> > >>> really useful makes the overall system more effective.
> > >>>
> > >>> Are there any particular combinations of arch, config, compilers
> > >>> you care about more than others?
> > >>>
> > >>> Thanks,
> > >>> Guillaume
> > >>>
> >