Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

kbuild: skip building kselftest when not required by jobfilter (speed up bisection)

Aperta
  • Qualcosa non va?
#3,127 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
50/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
build-system, ci-cd

Direzione di ricerca

Inizia da get_jobfilter() in src/lava_callback.py, quindi esamina config/jobs.yaml e config/scheduler.yaml per tracciare i test kselftest attraverso i collegamenti agli eventi fino ai relativi job di build. Confronta questo comportamento con la logica di filtraggio attuale in kernelci/kbuild.py. Il lavoro è completato quando i job kselftest richiesti mantengono gli artefatti necessari, mentre le build di bisezione non correlate saltano kselftest.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Goal

To speed up bisection, do not build kselftest when it isn't needed by the requested jobs (kselftest builds are expensive and dominate bisection turnaround).

This was originally attempted in #2729, but that approach needs more design work before it can land — see below. Converting to an issue to track the proper solution.

Current attempt (#2729)

In kernelci/kbuild.py, when a jobfilter is present, kselftest is disabled unless <build-name>-kselftest literally appears in the filter:

if node['jobfilter'] and self._kfselftest is True:
    kselftest_name = node['name'] + "-kselftest"
    if kselftest_name not in node['jobfilter']:
        self._kfselftest = False

Why this isn't enough

  1. Downstream tests are invisible to the build. kbuild.py runs in the build container and only receives node + params + a flat jobfilter list of strings. It has no knowledge of which tests consume kselftest artifacts. So a jobfilter containing a kselftest test (but not the kselftest build name) would silently produce a build without kselftest, and the test would fail mysteriously. The dependency knowledge lives in kernelci-pipeline:

    • test → needs-kselftest is identifiable from config/jobs.yaml (test_method: kselftest, kcidb_test_suite: kselftest.*)
    • build → test link is the event field in config/scheduler.yaml

  2. Possible naming bug. Dedicated kselftest build variants are already named kbuild-...-kselftest (e.g. config/jobs.yaml, scheduler.yaml). For such a node, node['name'] + "-kselftest" becomes kbuild-...-kselftest-kselftest, which never matches the filter — so kselftest would be disabled on the very build meant to produce it (this is exactly the bisection-of-a-kselftest-test path). Needs verification against real node['name'] values.

Proposed direction

Move the decision to kernelci-pipeline, which already has self._configs loaded and builds the jobfilter in get_jobfilter() (src/lava_callback.py):

  • When any requested job in the jobfilter resolves to a kselftest test (test_method == 'kselftest'), auto-enable kselftest on the corresponding build (e.g. set a kselftest: enable param on the build node, or ensure the kselftest-enabled build name is in the filter).
  • Otherwise, leave kselftest off so bisection builds stay fast.

The one non-trivial piece is reverse-resolving the scheduler graph (test → triggering build-node event → build job), since the build job doesn't inherently know its downstream tests. This is an in-memory config walk, not new infrastructure.

Closes #2729 (superseded by this issue).

Lingua principale
Python
Stelle
120
Fork
108
Merge medio
1g 12h
PR unite (30g)
21

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di kernelci/kernelci-core

Tutte le issue di kernelci/kernelci-core

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.