Короче, усаживайтесь поудобнее и слушайте программерскую байку о том, как вредно обзаводиться привычкой использовать одну и ту же систему имен в разных проектах.
Есть у меня проект P, и в нем есть скриптик для CI/CD. Скриптик обычно крутится в докере где-то там в облаке и ему нужен замонтированный диск с репозиторием. Он замонтирован в /workspace — это довольно часто встречающееся соглашение.
Для того, чтобы тестировать и править скриптик локально, без возни с докерами, на файловой системе рабочей машины сделана ссылка /workspace -> <реальное расположение репозитория>
Есть у меня и проект S, в котором студент фигачит код. Там тоже докеры-шмокеры, все такое и gradle в качестве системы сборки. И вот вчера, получив от студента очередной merge request и выполнив локально gradle test, я внезапно обнаруживаю, что в проекте P исчез с диска весь код, как корова языком. WTF? - громко думаю я. Грешу на сбой файловой системы или диска, но fsck уверяет что все пучком.
Ну ладно, благо все вроде было в гите. git clone проекта P, все такое, даже место лишнее освободилось на диске.
Но когда это случилось _снова_ я начал подозревать недоброе.
И действительно, в проекте S в коде, который запускается из тестов, и который вообще говоря рассчитывает на то, что его будут запускать в докере, делается rm -rf /workspace/* (и оно так и задумано, не ошибка)
¯\_(ツ)_/¯
Есть у меня проект P, и в нем есть скриптик для CI/CD. Скриптик обычно крутится в докере где-то там в облаке и ему нужен замонтированный диск с репозиторием. Он замонтирован в /workspace — это довольно часто встречающееся соглашение.
Для того, чтобы тестировать и править скриптик локально, без возни с докерами, на файловой системе рабочей машины сделана ссылка /workspace -> <реальное расположение репозитория>
Есть у меня и проект S, в котором студент фигачит код. Там тоже докеры-шмокеры, все такое и gradle в качестве системы сборки. И вот вчера, получив от студента очередной merge request и выполнив локально gradle test, я внезапно обнаруживаю, что в проекте P исчез с диска весь код, как корова языком. WTF? - громко думаю я. Грешу на сбой файловой системы или диска, но fsck уверяет что все пучком.
Ну ладно, благо все вроде было в гите. git clone проекта P, все такое, даже место лишнее освободилось на диске.
Но когда это случилось _снова_ я начал подозревать недоброе.
И действительно, в проекте S в коде, который запускается из тестов, и который вообще говоря рассчитывает на то, что его будут запускать в докере, делается rm -rf /workspace/* (и оно так и задумано, не ошибка)
¯\_(ツ)_/¯
Короче, усаживайтесь поудобнее и слушайте программерскую байку о том, как вредно обзаводиться привычкой использовать одну и ту же систему имен в разных проектах.
Есть у меня проект P, и в нем есть скриптик для CI/CD. Скриптик обычно крутится в докере где-то там в облаке и ему нужен замонтированный диск с репозиторием. Он замонтирован в /workspace — это довольно часто встречающееся соглашение.
Для того, чтобы тестировать и править скриптик локально, без возни с докерами, на файловой системе рабочей машины сделана ссылка /workspace -> <реальное расположение репозитория>
Есть у меня и проект S, в котором студент фигачит код. Там тоже докеры-шмокеры, все такое и gradle в качестве системы сборки. И вот вчера, получив от студента очередной merge request и выполнив локально gradle test, я внезапно обнаруживаю, что в проекте P исчез с диска весь код, как корова языком. WTF? - громко думаю я. Грешу на сбой файловой системы или диска, но fsck уверяет что все пучком.
Ну ладно, благо все вроде было в гите. git clone проекта P, все такое, даже место лишнее освободилось на диске.
Но когда это случилось _снова_ я начал подозревать недоброе.
И действительно, в проекте S в коде, который запускается из тестов, и который вообще говоря рассчитывает на то, что его будут запускать в докере, делается rm -rf /workspace/* (и оно так и задумано, не ошибка)
¯\_(ツ)_/¯
Есть у меня проект P, и в нем есть скриптик для CI/CD. Скриптик обычно крутится в докере где-то там в облаке и ему нужен замонтированный диск с репозиторием. Он замонтирован в /workspace — это довольно часто встречающееся соглашение.
Для того, чтобы тестировать и править скриптик локально, без возни с докерами, на файловой системе рабочей машины сделана ссылка /workspace -> <реальное расположение репозитория>
Есть у меня и проект S, в котором студент фигачит код. Там тоже докеры-шмокеры, все такое и gradle в качестве системы сборки. И вот вчера, получив от студента очередной merge request и выполнив локально gradle test, я внезапно обнаруживаю, что в проекте P исчез с диска весь код, как корова языком. WTF? - громко думаю я. Грешу на сбой файловой системы или диска, но fsck уверяет что все пучком.
Ну ладно, благо все вроде было в гите. git clone проекта P, все такое, даже место лишнее освободилось на диске.
Но когда это случилось _снова_ я начал подозревать недоброе.
И действительно, в проекте S в коде, который запускается из тестов, и который вообще говоря рассчитывает на то, что его будут запускать в докере, делается rm -rf /workspace/* (и оно так и задумано, не ошибка)
¯\_(ツ)_/¯
У записи 9 лайков,
0 репостов,
416 просмотров.
0 репостов,
416 просмотров.
Эту запись оставил(а) на своей стене Дмитрий Барашев
