On Wed, Jun 16, 2021 at 7:56 AM Arnaldo Carvalho de Melo
<arnaldo.melo@xxxxxxxxx> 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.
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?
> Now looking at that code, must be something subtle...
>
> - Arnaldo
