Я использую модули go на go1.12 для обработки своих зависимостей Go. Лучше всего также зафиксировать каталог vendor/ в системе контроля версий?
Это в некоторой степени связано с лучшей практикой зафиксировать каталог `vendor`? который задает этот вопрос в случае использования dep . С dep фиксация vendor/ — единственный способ получить действительно воспроизводимые сборки. Что насчет модулей go?
Если вам не нужно изменять пакеты поставщиков, вы не должны этого делать. Модули Go уже дают вам воспроизводимые сборки, поскольку файл go.mod записывает точные версии и хэши коммитов ваших зависимостей, которые инструмент go будет учитывать и следовать им.
Каталог vendor можно воссоздать, выполнив команду go mod vendor, и он даже игнорируется по умолчанию go build, если только вы не попросите его использовать его с флагом -mod=vendor.
Подробнее:
Перейти wiki: Как мне использовать вендорство с модулями? Торговля исчезнет?
Команда go: модули и поставщики
Команда go: создание копий зависимостей от поставщиков
Я хотел бы привести несколько аргументов в пользу совершения vendor, go.mod и go.sum.
Я согласен с аргументами принятого ответа о том, что это технически не нужно и раздувает репо.
Но вот список контраргументов:
Сборка проекта не зависит от того, какой код доступен на Github/Gitlab/... или на прокси-серверах Go. Проекты с открытым исходным кодом могут исчезнуть из-за цензуры, поощрений авторов, изменений в лицензировании или по другим причинам, о которых я сейчас не могу думать, которые произошло с npm, диспетчером пакетов JavaScript, и сломало многие проекты. Ни в вашем репозитории, ни в вашем коде.
Возможно, мы использовали внутренние или сторонние модули Go (частные), которые также могут исчезнуть или стать недоступными, но если они переданы поставщику, они являются частью нашего проекта. Ничто не ломается неожиданно.
Частные модули Go могут не следовать семантическому управлению версиями, а это означает, что инструменты Go будут полагаться на последний хэш фиксации при их извлечении на лету. История репозитория может быть переписана (например, перебазирована), и вы, коллега или ваша работа CI можете получить другой код для зависимостей, которые они используют.
Обязательный поставщик может улучшить ваш процесс проверки кода. Обычно мы всегда фиксируем изменения зависимостей в отдельной фиксации, чтобы их можно было легко просмотреть, если вам интересно.
Вот интересное наблюдение, связанное с раздуванием репо. Если я делаю обзор кода, и член команды включил новую зависимость с 300 файлами (или обновил зависимость с 300 измененными файлами), мне было бы очень любопытно углубиться в это и начать обсуждение качества кода, необходимости этого изменения. или альтернативные модули Go. Это может привести к уменьшению размера двоичного файла и общей сложности.
Если я увижу только одну новую строку в go.mod в новом запросе на слияние, скорее всего, я даже не подумаю об этом.
go build -mod vendor)Это у меня на голове, если что-то еще вспомню, добавлю сюда.
