Politikker for sletning af hooks

Det mest almindelige valg er hook-succeeded. Helm sletter hook-ressourcen, lige efter at den er fuldført uden fejl, så namespace'et holdes ryddeligt.

Med hook-succeeded bliver et mislykket hook med vilje efterladt. Du kan læse dets logfiler for at se, hvorfor migreringen gik galt, før du rydder op manuelt. 🔍

Den modsatte politik er hook-failed. Helm fjerner kun hook-ressourcen, når den mislykkes, hvilket passer til hooks, du helst ikke vil lade ligge i en ødelagt tilstand.

Den tredje mulighed er before-hook-creation. Helm sletter den tidligere instans, lige før den nye oprettes, så kollisioner med uforanderlige navne undgås.

Hvis du slet ikke angiver en politik, bruger Helm som standard before-hook-creation. Det gamle hook fjernes, lige før den næste kørsel opretter det igen.

Politikker kan kombineres i en kommasepareret liste. Hvis du kombinerer before-hook-creation med hook-succeeded, fjernes forældede kørsler, og der ryddes op efter hver succes.

Et Jobs specifikation kan ikke ændres, efter at det er oprettet. before-hook-creation undgår problemet ved først at slette det gamle Job, så hver opgradering får et nyt.

Vælg den politik, der passer til dit mål: ryd op ved succes, bevar dokumentation for fejl, eller start altid på en frisk. Hver annotation besvarer blot spørgsmålet om, hvornår der skal slettes.

Disse politikker gælder kun for ressourcer, som Helm har oprettet som hooks. Helm holder styr på dem og sletter dem for dig, så du undgår manuel kubectl delete efter hver release.

hook-delete-policy vælger, hvornår Helm fjerner et hook: ved succes, ved fejl eller før næste oprettelse. Standardværdien er before-hook-creation. 🧹