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

docs(cookbook): engine-verified path idioms — membership, at-least-one, and the traps

Aperta
  • Qualcosa non va?
#324 0 commenti 0 reazioni 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
48/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kubernetes, python, terraform
Ambito
documentation

Direzione di ricerca

Inizia individuando la documentazione del cookbook e i punti di ingresso per la verifica del motore in esecuzione, quindi confronta ogni ricetta tra il motore condiviso json/kubernetes e terraform_plan. Usa eval_expression per il comportamento della guard e preserva gli edge case elencati, le limitazioni dei motori e la gestione dei tipi; la pagina completata dovrebbe indicare ogni idioma con i motori che lo supportano. Mantieni il traceback di utils.sort_collections come bug separato.

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

Descrizione

documentation

A cookbook page of zero-code recipes, each verified against the running engine. House rule: every
path idiom names which of the two path engines it holds for — the shared json/kubernetes engine
and terraform_plan disagree more often than they agree, and "true idiom, wrong engine" fails
silently.

  • Collection membership: drop the trailing .* and the provider emits the whole collection as
    one value per resource; Contains with an element dict is membership. Limit: exact element
    equality (fails where elements carry extra keys, e.g. aws_db_parameter_group.parameter with
    apply_method).
  • At-least-one via guard && !none: !id is existential in eval_expression, so De Morgan
    applies — an IsNotEmpty guard on the collection, a Not* condition on
    <collection>.*.<field>, and eval_expression: "guard && !none". Verified across matching /
    non-matching / empty-array / absent-key / empty-document cases. The guard is load-bearing:
    without it an absent collection satisfies the negation vacuously. Caveat, measured: on
    terraform_plan this is plan-wide, not per-resource (the provider flattens instances into one
    stream — two resources where only one matches returns true); sound for single-instance json
    documents and genuinely plan-wide intent only. It cannot bind two attributes of the same element,
    and the negated condition cannot be a regex.
  • Scalar-or-list: a trailing .* unwraps a scalar on the shared json/kubernetes engine, so one
    path covers a scalar-or-list union (Statement.*.Action.*). It does not hold on
    terraform_plan, where a scalar under .* is a severity-2 miss.
  • * iterates dict values, so CloudFormation's Resources map addresses exactly like ARM's
    array.
  • An empty list pads None at inner wildcard levels; only the outermost segment is a severity-2
    miss — this decides error_tolerance for nested-block-inside-repeated-block checks.
  • When every id is deleted from the AST the result is null, not true — the trap for
    all-absence policies, whose compliant case is exactly "every path misses".
  • The type-guard idiom is polarity-specific: type present + attribute absent FAILS at every inner
    tolerance, so omit the guard when upstream passes on absence; use !selected || check for
    sibling-attribute scoping.
  • nullable.TypeNullableBool provider arguments arrive in the plan as the strings
    "true"/"false", so Equals: true silently never fires — use ContainedIn: [true, "true"].

Related bug, fileable separately: a mixed-type list in ContainedIn/Equals evaluates correctly
but logs a full traceback from utils.sort_collections — cosmetic, noisy, ~2-line fix.

Lingua principale
Python
Stelle
167
Fork
47
Merge medio
2h 44m
PR unite (30g)
5

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 StackGuardian/tirith

Tutte le issue di StackGuardian/tirith

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.