LINUX.ORG.RU

Версия моего ПО

 ,


2

1

Всем привет, сейчас осознал, что не знаю как красиво сделать.

Вот есть некая программа (rust / node.js), вот есть git, вот есть теги и ветки. И допустим в интерфейсе я хочу отображать актуальную версию сборки.

Как лучше всего это сделать? Ручками менять файлик version.txt или все же есть более красивый вариант?

★★★★

Ответ на: комментарий от Crocodoom

Ну в расте не кошерно же, там cargo. Но теперь понятно как получать версию и в gitlab-ci просто буду обновлять файл.

AntonyRF ★★★★
() автор топика

Мудаки вызывают git describe во время сборки, не понимая что во-первых это добавляет бесполезную build-зависимость от git, во-вторых ломается если исходники скачаны не из git, а бывает что подцепляет версию от вообще не связанного репозитория, когда .git есть в корне, в ~ или где-то ещё выше по дереву каталогов.

Обычно у тебя так или иначе версия определена в каком-то манифесте, типа project(foo VERSION 1.2.3) в CMake, version в package.json, setup(version=) в setup.py и т.д., и этого достаточно.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Мудаки вызывают git describe во время сборки, не понимая что во-первых это добавляет бесполезную build-зависимость от git, во-вторых ломается если исходники скачаны не из git, а бывает что подцепляет версию от вообще не связанного репозитория, когда .git есть в корне, в ~ или где-то ещё выше по дереву каталогов.

Никто же не мешает проверять, есть ли в корне дерева исходников файл или каталог .git, и по-нормальному обрабатывать случай, когда git describe (или git rev-parse) не работает.

Обычно у тебя так или иначе версия определена в каком-то манифесте

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

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 2)
Ответ на: комментарий от proud_anon

Никто же не мешает проверять, есть ли в корне дерева исходников файл или каталог .git, и по-нормальному обрабатывать случай, когда git describe (или git rev-parse) не работает

обрабатывать случай, когда git describe не работает

Ну т. е. иметь ещё один алгоритм, на случай отсутствия гита. Зачем тогда гит вообще нужен здесь? Вопрос риторический, если что.

cppsektant
()
Ответ на: комментарий от cppsektant

Ну т. е. иметь ещё один алгоритм, на случай отсутствия гита. Зачем тогда гит вообще нужен здесь?

Ну если есть гит, то вставлять хэш коммита, а если нет, то не вставлять. Или, например, в релизные архивы исходников класть файл с номером ревизии, а кто прямо из Гита собирает, тому номер ревизии из Гита. А у кого ни того, ни другого нет, тому строку «UNKNOWN».

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

Никто же не мешает проверять, есть ли в корне дерева исходников файл или каталог .git, и по-нормальному обрабатывать случай, когда git describe (или git rev-parse) не работает.

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

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

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

slovazap ★★★★★
()

Только ручками. Всё остальное - быдлокод, который работает только на машине автора.

RazrFalcon ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.