Обеспечение повторяющегося порядка каталогов в linux

16

Я управляю компанией по непрерывной интеграции , и мы запускаем код наших клиентов в Linux. Каждый раз, когда мы запускаем код, мы запускаем его на отдельной виртуальной машине. Частая проблема, которая возникает, заключается в том, что пользовательские тесты иногда не выполняются из-за упорядочения каталога их кода, проверенного на виртуальной машине.

Позвольте мне перейти к более подробно. В OSX файловая система HFS + гарантирует, что каталоги всегда перемещаются в одном и том же порядке. Программисты, использующие OSX, предполагают, что если он работает на их компьютере, он должен работать везде. Но это часто не работает в Linux, потому что файловые системы Linux не предлагают гарантий упорядочения при обходе каталогов.

В качестве примера рассмотрим 2 файла: a.rb, b.rb. a.rb определяет MyObject, а b.rb использует MyObject. Если a.rb загружается первым, все будет работать. Если b.rb загружается первым, он попытается получить доступ к неопределенной переменной MyObjectи потерпит неудачу.

Но что еще хуже, это то, что он не всегда просто терпит неудачу. Поскольку порядок файловой системы в Linux не упорядочен, это будет другой порядок на разных машинах. Это хуже, потому что иногда тесты проходят, а иногда они не проходят. Это худший из возможных результатов.

Итак, мой вопрос, есть ли способ сделать порядок файловой системы повторяемым. Может быть, есть какой-то флаг в ext4, который говорит, что он всегда будет проходить каталоги в каком-то порядке? Или, может быть, другая файловая система, которая имеет эту гарантию?

— Пол Биггар
источник

2

Случайный порядок на OSX .

— Phihag

Помимо действительно верных ответов - что такое «правильный» порядок? Просто отсортировано по алфавиту? Или по CTIME? Произвольно магически? Как клиенты обеспечивают этот заказ при развертывании? Как вам передать эту магическую информацию?

— Мичуельник

@Michuelnik Нет реального правильного порядка, но что-то повторяемое означало бы, что мы каждый раз получаем один и тот же результат, который был бы лучше, чем ничего. В идеале мы бы использовали порядок HFS +, который я считаю алфавитным.

— Пол Биггар

@Michuelnik Эта проблема затрагивает тесты гораздо больше, чем развертывание. Развертывание в основном происходит в Linux, но если что-то не получается, они исправят это. Тесты в основном выполняются на OSX, поэтому, если что-то не получается, это наша вина

— Пол Биггар

1

@PaulBiggar: Я понимаю вашу проблему и не могу предложить хорошее решение (если вы не можете найти способ определить , является ли причиной проблемы причина в порядке файлов). Но я не согласен с тем, что «повторяющийся успех лучше, чем непоследовательный отказ»: если моя среда разработки (и CI) имеет повторяющийся успех, но моя платформа развертывания имеет синдром «ненадежного отказа», то я действительно в плохом положении. Я бы скорее увидеть недостоверную неудачу как можно скорее ( в идеале на моей системе развития , но , по крайней мере на моей системе CI).

— Иоахим Зауэр

16

Я знаю, что это не тот ответ, который вы ищете, но я считаю, что правильное решение - избегать зависимости от порядка файлов в каталоге. Может быть, он всегда одинаков для всех файловых систем HFS +, и, возможно, вы сможете найти способ сделать его согласованным в ext4 или другой файловой системе, но в долгосрочной перспективе это будет стоить вам больше хлопот, чем спасет. Кто-то, кто использует ваше приложение, может удивиться, когда не поймет, что оно совместимо только с некоторыми типами файловых систем, а не с другими. Порядок может измениться, если файловая система будет восстановлена из резервной копии. Вероятно, вы столкнетесь с проблемами совместимости, поскольку согласованный порядок HFS + и согласованный порядок ext4 могут не совпадать.

Просто прочитайте все записи каталога и рассортируйте список лексикографически перед использованием. Так же, как и lsделает.

Вы упоминаете файлы a.rbи b.rb, но если мы говорим об исходных файлах языка программирования, не должен ли каждый файл уже отвечать за то, чтобы он импортировал все свои зависимости?

— Celada
источник

Проблема в том, что мы не написали код, который запускаем. Мы запускаем код клиента и не можем контролировать, как он был написан. Так что наша проблема в том, что нас обвиняют в этой проблеме, потому что она работает на их машине, а не на нашей. Если бы мы могли заставить всех писать правильный код, мы бы так и сделали, но это не в наших силах :)

— Пол Биггар

10

@PaulBiggar: но разве «он работает здесь, но не в производстве» - это именно та проблема, которую должен решить КИ? Другими словами: «Почему мой код ломается в вашей системе?» следует ответить "Потому что мы делаем именно то, что вы просите нас!" ;-)

— Иоахим Зауэр

4

Я не знаю ни о ком другом, но когда код работает на моей машине, а затем не удается выполнить КИ или проверку коллеги, я сразу же предполагаю, что есть что-то, зависящее от платформы или среды, которое мне нужно исправить ...

— matt5784

1

Неужели разработка приложения на платформе, которую вы не будете использовать в производстве, - плохая идея? Заставьте их развиваться на той же платформе, для которой они пишут.

— Мэтью Ифе

2

Я не согласен. Я думаю, что это отличная идея. При переходе от разработки к тестовым серверам появляется гораздо больше ошибок. И, следовательно, код становится гораздо более надежным, прежде чем он перейдет на рабочие серверы. Так что в правильном или теоретическом мире это намного лучше. Это тот же мир, где вы можете заставить каждого написать правильный код, также известный как сказочная страна.

— Хеннес

5

Вызов POSIX в Linux readdir () не гарантирует какого-либо последовательного упорядочения. Если вам нужны упорядоченные результаты, приложение, обрабатывающее файлы, отвечает за порядок их представления вызывающим функциям.

/programming/8977441/does-readdir-guarantee-an-order

Теперь, поскольку вы сказали, что это код вашего клиента, и вы не можете его исправить, вы можете изменить связанные библиотеки, которые используются для обеспечения согласованного вызова readdir (). Это заняло бы некоторую работу и стоило бы своего собственного вопроса. Для быстрой ссылки на это см. Http://www.ibm.com/developerworks/linux/library/l-glibc/index.html .

Изменение этого может породить некоторые другие целые серии проблем, которые я, возможно, не смогу предвидеть. Вас настоятельно предупреждают, но это может быть решением, если ваш клиент не может быть должным образом обучен.

— Джефф Ферланд
источник

1

Обучите своего клиента, что есть внутренняя зависимость заказа, которая должна быть четко указана. Предложите клиенту помочь выразить зависимость таким образом, чтобы компиляция работала на всех системах, и чтобы клиент принял измененный поток, который фиксирует зависимость порядка компиляции.

Если клиент хочет иметь возможность компилировать на других машинах, он считает, что это бесплатно.

— Paddy3118
источник

Мы определенно собираемся сделать это. Однако было бы полезно, если бы они действительно стали нашими клиентами, чтобы мы могли это сделать.

— Пол Биггар

0

Современный Linux (ext4) добавляет индекс B-дерева для списков файлов. Одним из его эффектов является порядок файлов по умолчанию, который зависит от хэша их имен.

Чтобы отключить эту функцию, используйте:

tune2fs -O ^ dir_index

— Ага
источник