- Navios
- 3 de setembro de 2026 às 05:44 UTC
- Autor
- Kamo
- Enviar
- 310f3c0
O ceifeiro adicionado em 199e367e comparou o commit de cada recipiente contra github.sha e KEPT as partidas, na teoria de que um sha correspondente significava "isto correr". Isso é errado exatamente quando uma execução é re-triggered para o mesmo commit: o construção velha carrega o mesmo sha, assim que o guarda protegeu o único recipiente o O passo existe para matar. Apanhei-o a fazer isso. TASK-10531 (cancelado, 30 minutos dentro) e TASK-10532 (vivo) estavam ambos construindo 199e367e; o ceifeiro de 10532 olhou para o órfão de 10531, viu o seu próprio sha, e guardou-o. Duas construções novamente, e o ceifeiro relatou sucesso. A regra correcta é mais simples do que a que escrevi. Nesse ponto do trabalho nosso o próprio buildx não foi iniciado, então cada buildx interno do kamo na máquina pertence a uma corrida anterior, e o grupo de concorrência permite exatamente uma. Eles são todos substituído. Matar todos eles — sem comparação sha, sem janela de idade, nada para obter sutilmente errado. Ainda está no escopo desta imagem, então o kbservice e o serviço de segurança constroem o compartilhamento do corredor são intocados, e ainda com a chave no processo buildx dentro do recipiente em vez do próprio recipiente de ato, cujo comando é `tail -f /dev/null`. Correr a seco contra o corredor ao vivo antes de cometer: colhe o kamo-interno construir, ignora o trabalho de sincronização do dicionário.