https://github.com/ndmitchell/rattle - клёвая штука

тоже посмотри на https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container-example

Спс

не везде доступно

тех, кто отстаёт на 3 версии уже ничто не спасёт)

оно в альфе, в GKE его не будет даже на последних версиях

ну если всё на столько плохо, то https://github.com/aylei/kubectl-debug

самый простой вариант - зайти на ноду и там дебажить

зачем оно

простая система сборки, берёт тупой скрипт и распарралеливает, делает инкрементальные билды и тд

как оно соотносится, например, с prow?

при этом не надо указывать зависимости и тд

никак, это система сборки, заменяет make

можно использовать не только для сборки, но и для любой системы генерации контента

идея в rattle интересная. Ты ему скармливаешь скрипт, который сам по себе может "компилировать" софт, он его анализирует и понимает, какие команды можно выполнять параллельно, какие можно не перезапускать в случае инкрементальной сборки

прикольно, спасибо

простой пример

# make.sh
gcc main.c -o main.o
gcc util.c -o util.o
link main.o util.o -o main.exe

тут rattle поймёт, что первые две команды можно параллельно запускать, что link зависит от 2х предыдущих и при инкрементальном билде не будет пересобирать util если он не поменялся

при этом тебе не надо ничего помечать, какие-то метаданные в билд запихивать, rattle всё делает сам

они тестировали сборку проекта на nodejs - добились параллелизма, который продвинутая система сборки не смогла дать. Потому что они вычисляют зависимости автоматом, а человек зависимости может указать неправильно (либо лишние, либо забыть)

ещё они используют спекуляции: то есть запускают команды заранее, ещё не зная, изменились ли входные файлы (которые могут быть обновлены предыдущими командами). Если вдруг получится, что изменились - то команда перезапустится, если нет, то результат уже готов. Ну то есть механизм схожий с branch prediction в CPU