Re: latest pahole breaks libbpf CI and let's talk about staging

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Wed, Jun 16, 2021 at 10:40:45AM -0700, Andrii Nakryiko escreveu:
> On Wed, Jun 16, 2021 at 7:56 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Tue, Jun 15, 2021 at 04:30:03PM -0700, Andrii Nakryiko escreveu:
> > > Hey Arnaldo,
> > >
> > > Seems like de3a7f912559 ("btf_encoder: Reduce the size of encode_cu()
> > > by moving function encoding to separate method") break two selftests
> > > in libbpf CI (see [0]). Please take a look. I suspect some bad BTF,
> > > because both tests rely on kernel BTF info.
> > >
> > > You've previously asked about staging pahole changes. Did you make up
> > > your mind about branch names and the process overall? Seems like a
> > > good chance to bring this up ;-P
> > >
> > >   [0] https://travis-ci.com/github/libbpf/libbpf/jobs/514329152
> >
> > Ok, please add tmp.master as the staging branch, I'll move things to
> > master only after it passing thru CI.
> >
> 
> So I'm thinking about what's the best setup to catch pahole staging
> problems, but not break main libbpf CI and kernel-patches CI flows.
 
> How about we keep all the existing CI jobs to use pahole's master.

Agreed.

> Then add a separate job to do full kernel build with pahole built from
> staging branch. And mark it as non-critical (or whatever the
> terminology), so it doesn't mark the build red. I'd do that as a cron
> job that runs every day. That way if you don't have anything urgent,
> next day you'll get staging tested automatically. If you need to test
> right now, there is a way to re-trigger previous build and it will
> re-fetch latest staging (so there is a way for you to proactively
> test).
> 
> Basically, I want broken staging pahole to not interrupt anything we
> are doing. WDYT?

Sounds like a plan, please hand hold me on this, I'm not versed on
github.

- Arnaldo
 
> > Now looking at that code, must be something subtle...
> >
> > - Arnaldo

-- 

- Arnaldo