Тип ресурса в Concourse CI: что произойдет, если проверка всегда возвращает только последнюю версию?

Я просматривал ресурс git, и мне показалось любопытным, что Check делает клон, а не гораздо более легкий ls-remote. Я думаю, что есть две причины:

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

Первое очевидно, но я не вижу причин для второго.

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

Но потом он говорит:

Если ваш ресурс не может определить, какие версии новее заданной версии (например, если это git-коммит, который был принудительно загружен), то должна быть возвращена текущая версия вашего ресурса (т. е. новый HEAD).

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

Обратите внимание, что этот вопрос связан с Реализован тип ресурса: как Concourse использует выходные данные сценариев проверки, входа и выхода?


concourse concourse-git-resource
person squashed    schedule 28.07.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если бы вы сделали это таким образом, ваши ресурсы появились бы с одним набором версий, и ваши шаги get не вернули бы версию файла, которая была явно запрошена (версия, возвращенная check, передается in), что было бы нарушение дизайна типа ресурса и, честно говоря, плохая практика (зачем возвращать то, что не было запрошено, только потому, что оно новее? что, если вам нужно привязать ресурс к определенной версии?)

Ответ на вопрос, почему ресурс git делает clone вместо ls-remote, заключается в том, что вы можете настроить ресурс для распознавания новых версий только в случае изменения определенных файлов (или наоборот, если была новая фиксация, но измененные файлы находились в ignore_paths раздел исходной конфигурации, check не возвращает новый ресурс.

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

person Josh Ghiloni    schedule 09.08.2020
comment
Да, это в основном производительность. У нас есть несколько репозиториев, размер которых, к сожалению, превышает 20 ГБ. (они получены от внешних поставщиков и настроены так, чтобы следовать им). Этап проверки имеет большое значение даже при кэшировании. - person squashed; 24.08.2020
comment
ваши шаги получения не вернут версию файла, которая была явно запрошена (версия, возвращенная проверкой, передается в) Хорошо, в случае закрепления я предполагал, что шаг in все равно будет работать с точным хешем, но это звучит как будто он все еще фильтруется при проверке и может быть изменен по ходу дела? - person squashed; 24.08.2020