Re: Please add new Android branches

Guillaume, any ETA on when we can ramp up the Android tests as
discussed on this thread?


On Tue, Oct 17, 2023 at 1:42 PM Todd Kjos <[email protected]> wrote:
>
> 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
> > > >>>
> > >