Use dynamic test origins instead of hardcoded list
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
Direzione di ricerca
Inizia dall’endpoint /origins e verifica come l’elenco dell’hardware applica i filtri sull’origine dei test. Esamina la tabella tests e il lavoro sullo schema orientato all’analisi in #1947 prima di scegliere il percorso della query. Il lavoro è completato quando le origini provengono da dati distinti di tests, le nuove origini compaiono entro il TTL della cache, il filtraggio dell’hardware rimane corretto e l’endpoint resta veloce sotto un carico normale.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Hardware origin dropdown still uses a hardcoded TEST_ORIGINS list. New origins only appear after a code change (#1983).
Goal
Load test_origins from the tests table (distinct origins in the requested interval), with caching.
Why not hardware_status
That table only includes tests with a platform. The dropdown would miss test origins that never appear on a platform. We need origins from tests itself.
Dependency
A direct distinct over current tests is too slow (previously ~minutes / timeouts). This should wait on the analysis-oriented schema work in #1947 (e.g. leaner run facts), which should make this query practical.
Acceptance criteria
-
/originsservestest_originsfromtestsdata, not a static list - New origins appear without a code change (within cache TTL)
- Hardware listing still filters correctly by test origin
- Endpoint stays fast under normal load
Related
- #1983
- #1947
- Lingua principale
- Python
- Stelle
- 10
- Fork
- 32
- Merge medio
- 5g 13h
- PR unite (30g)
- 23
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di kernelci/dashboard
-
4xx and 5xx by endpointForse già presa @alanpeixinho l’ha presa 5 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
Requests per visitorAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
kernelci/dashboard#2151 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Requests and latency by endpoint, split by clientForse già presa @alanpeixinho l’ha presa 5 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di kernelci/dashboard
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
rpm-software-management/mock#1824 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
jpata/particleflow#520 ·
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue hacktoberfest
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
gridhead/gi-loadouts#699 ·
I maintainer di solito rispondono entro 13 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
FinanceFlash/unvibecode#206 ·
I maintainer di solito rispondono entro 1 giorno