[Feature] Define smoke and integration scopes for Kubernetes runs
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 22/100
Direzione di ricerca
The issue names no specific files or tests. Start by auditing the existing VIP markers and listing which scenarios carry each one, then check how the current selection mechanism picks them. Done means the smoke and Kubernetes integration scenario sets are documented, each can be selected on its own, and no test that needs bootstrapped product state is in the smoke set. Agreeing the scope with maintainers comes first.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Define a stable VIP marker contract for selecting Kubernetes smoke and integration scenarios without conflating them with VIP's containerized CI suites.
Affected area
Other / not sure
What problem are you trying to solve?
The images-build workflow currently selects only smoke scenarios, while broader scenarios may depend on product configuration or seeded state. Selecting all tests by default would run scenarios without their required environment and could produce misleading skips or failures.
Proposed solution
Audit the current VIP markers and agree which scenarios are suitable for the Kubernetes smoke scope versus a bounded integration scope. Keep smoke fast and independent of seeded state; document integration prerequisites and make its selection explicit. Keep this scope contract distinct from the containerized CI coverage tracked in VIP's existing CI work.
Acceptance criteria:
- The intended smoke and Kubernetes integration scenario sets are documented.
- The existing marker/selection mechanism can select each set independently and predictably.
- Tests that require bootstrapped product state are not selected as smoke tests.
Alternatives considered
Selecting every product test for integration runs would couple the workflow to unrelated categories and environment assumptions; selecting tests by ad hoc name filters would be difficult to maintain.
Related:
- Lingua principale
- Python
- Stelle
- 8
- Fork
- 1
- Merge medio
- 2g 8h
- PR unite (30g)
- 41
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna 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 posit-dev/vip
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
documentation team: connect
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
posit-dev/vip#734 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
team: workbench
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
posit-dev/vip#274 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 54/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di posit-dev/vip
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
fossasia/visdom-dev#77 ·
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
aws-cloudformation/cfn-lint#4890 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
volcengine/OpenViking#6521 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
AstrBotDevs/AstrBot#10720 ·
I maintainer di solito rispondono entro 1 giorno