Здравствуйте, netch80, Вы писали:


N>То есть ты хочешь сказать, что запустив одну и ту же задачу для bazel на Debian, RHEL и Windows, ты получишь бинарники идентичного поведения?
По-хорошему, это так и должно быть.
N>И как это "идентичное поведение" от Debian поможет на Windows, и наоборот?
Прекрасно поможет. У меня может быть билд-ферма, построенная на линухах в облаке. При этом я веду локальную разработку под виндой, и нафиг мне не упал запуск всякого говна в виртуалках.
Если я собираю линуховый бинарь, то я должен уметь его собрать и на винде, и в макоси, и в дебиане, и в убунту.
Если я собираю виндовый бинарь, то я должен уметь его собрать и на винде, и в макоси, и в дебиане, и в убунту.
N>Только вот почему-то в докер-контейнерах почти всегда или подмножество той же "помойки", или (для любителей статической сборки) результат обработки той самой помойки.
Внутри контейнера это всё неважно. Там может вообще руками программист всё подшаманил так, что воспроизвести эту сборку уже ничем невозможно. Это ж чорный ящик.
С точки зрения процесса разработки это отстой, а вот с точки зрения развёртывания — самое то.
Это как софт под винду, гвоздями прибитый к папке "C:\NALOGI". Можно бить разработчиков палкой, обучая их развёртывать софт внутри миллионов вариантов енвайронмента, а можно сказать им "да пёс с вами, настраивайте как хотите — лишь бы снаружи оно работало".

N>А для закатывающих солнце вручную, типа Go, остаётся зависимость от версии ядра.
N>Какой твой следующий шаг для решения этой проблемы?
Следующий шаг — не контейнер, а честная виртуалка.