Slettingspolicyer for hooks

Det vanligste valget er hook-succeeded. Helm sletter hook-ressursen rett etter at den er fullført uten feil, slik at namespace-et holder seg ryddig.

Med hook-succeeded blir en hook som feiler, liggende med vilje. Du kan lese loggene for å se hvorfor migreringen mislyktes, før du rydder opp manuelt. 🔍

Den motsatte policyen er hook-failed. Helm fjerner hook-ressursen bare når den feiler, noe som passer for hooks du helst ikke vil la ligge igjen i ødelagt tilstand.

Det tredje alternativet er before-hook-creation. Helm sletter den forrige instansen rett før den nye opprettes, slik at konflikter med uforanderlige navn unngås.

Hvis du ikke angir noen policy, bruker Helm before-hook-creation som standard. Den gamle hooken fjernes rett før neste kjøring oppretter den på nytt.

Policyer kan kombineres i en kommaseparert liste. Hvis du kombinerer before-hook-creation med hook-succeeded, fjernes gamle kjøringer, og det ryddes opp etter hver vellykkede kjøring.

Spec-en til en Job kan ikke endres etter at den er opprettet. before-hook-creation unngår dette ved å slette den gamle Job-en først, slik at hver oppgradering får en ny.

Velg policyen som passer målet ditt: rydd opp ved suksess, behold spor etter feil, eller start alltid på nytt. Hver annotasjon svarer bare på når ressursen skal slettes.

Disse policyene gjelder bare ressurser Helm har opprettet som hooks. Helm holder oversikt over dem og sletter dem for deg, slik at du slipper å kjøre kubectl delete manuelt etter hver release.

hook-delete-policy bestemmer når Helm fjerner en hook: ved suksess, ved feil eller før neste opprettelse. Standardverdien er before-hook-creation. 🧹