Re: Please add new Android branches

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
> >>>
>