GitHub отменил изменения метода формирования генерируемых архивов после сбоя

[dartraiden]

GitHub с выпуском 2.38 в инструментарии Git включила по умолчанию встроенную реализацию gzip

Как я понимаю, не гитхаб, а разработчики Git в этой версии перешли на использование встроенного gzip. Соответственно, как только гитхаб проапгрейдил Git на своей стороне, то словил это изменившееся поведение. Так что, это не гитхаб «включил по умолчанию». У гитхаба выбора-то особого нет: или терпеть, или откатываться на предыдущую версию (что и сделали), или патчить Git.

[Evengard]

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

[crackedmind]

Речь не про релизы, а то что код можно скачать архивом по любому коммиту, поэтому логично что оно создаётся на лету

[Evengard]

Кхм, это странно, рассчитывать на такой механизм. Специально для этого тегирование и релизы же придумали, разве нет?

[funca]

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

[funca]

Там можно скачать архив буквально для каждого комита. Создавать и хранить их явным образом было бы расточительством.

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

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

В случае с архивами, git справедливо пишут, что для данного инструмента они могут гарантировать лишь идентичность содержимого после распаковки, но не самих архивов.