- Shipped
- 8 de setembro de 2026 às 14:51 UTC
- Author
- Kamo
- Commit
- 6852acb
Reconstruir este serviço sem um commit próprio — um workflow dispatch, um re-run, ou uma mudança na biblioteca compartilhada com kamo que ele deve pegar — tem falhado em implant k1m1 para pelo menos as duas últimas tentativas (#673 e #674). O guarda estava lá e foi derrotado pelo passo acima. Ele comparou a imagem referência antes e depois de 'set image', sobre o raciocínio que uma mesma A reconstrução produz uma referência idêntica e, portanto, um no-op silencioso. Mas "Aplicar 'kubectl apply -f k8s/deployment.yaml', cuja imagem é `:latest` — portanto, «antes» é SEMPRE «:último» e «depois» é SEMPRE o SHA. Eles diferem em Cada execução, incluindo o único caso para o qual existe a verificação. A consequência não era um falso verde. Foi pior de uma forma mais útil: reinício nunca disparado, o pré-existente SHA ReplicaSet já estava disponível, assim `rollout status` retornou instantaneamente contra pods de 13 horas, e o digest verificação corretamente falhou o trabalho sem causa óbvia. O digest é a única coisa que pode distinguir uma imagem fresca de um velho — que o comentário já dito — então peça-o diretamente em vez de inferir de um referência a duas etapas escritas. 'rollout status' se move acima da verificação então Há vagens para ler uma digestão. Encontrado ao reconstruir este serviço para recolher o ServiceType. Holdem, que é o que O catálogo Apps & Features e todos os editores de permissões leram do seu frasco. Entretanto, essa divulgação foi concluída à mão.