Никак. Есть два (три) бранча — devel, stable (X.Y/2) и oldstable (X.Y/2-1). Версионируем лапками, бэкпортируем лапками, тестируем по большей части тоже лапками, как в старые-добрые времена.

у женьки есть BUILD_NUMBER, переменная, которую можно как раз для этих целей использовать - https://wiki.jenkins.io/display/JENKINS/Building+a+software+project

кури доки в общем

Не забываете версионировать лапками-то?

у женьки есть BUILD_NUMBER, переменная, которую можно как раз для этих целей использовать

Я не понял, ты это сам используешь или мне предложил? У меня цель – хранить версию в гите.

А нахрена версия в этом случае и что-то сохранять в реп? Для идентификации релизов возьмите просто хэш или номер коммита от корня или текущее время.

Нет, потому что стабилизация происходит не абы как, а выдёргиванием определённых коммитов из devel в stable, предварительно скопировав stable в oldstable.

Если действовать по современной модели разработки, дерьмо случается очень часто, а за дерьмо не платят.

Пусть система сборки запрашивает дёргает git describe с нужными флагами, это и будет версией.

ты дурачек чтоль?

Как вы автоматически инкрементируете номер версии в этом вашем continuous deployment

перечитай еще раз название своей темы

Чтобы по желанию левой пятки мажорный номер руками обновить.

Как Вам уже посоветовали выше - изучайте документацию. Там практически на все случаи есть готовые решения. Придумывать ничего не нужно.

Я две минуты потратил на то, чтобы тебя вежливо спросить, отвечаешь ли ты на вопрос из темы, а ты обзываешься. Перечитай сам, ну.

ну ты душнила, ужас… отвечаю на твой вопрос - да, использую

Что ещё за мажорный номер? У вас нет никаких мажорных номеров и семантического версионирования если у вас каждый коммит катится в прод.

чувак, забей

топикстартер сам не знает чего хочет…

Семантического версионирования нет, мажорный номер есть.

Пример: есть файл version.txt, в нём лежит <major>.<minor>. Минор должен обнавляться автоматически. В любой момент можно руками закоммитить <major+1>.0.

Катится не каждый коммит, а каждый коммит в мастер и не в прод, а в тест.

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

Хочу чтобы можно было зачекаутить коммит и прочитать из version.txt полный номер.

Если не выйдет, то сделаю как-то так.

Хочу чтобы можно было зачекаутить коммит и прочитать из version.txt полный номер.

Тогда коммить ещё раз на каждый коммит и страдай, собственно в чём вопрос-то?

Тогда коммить ещё раз на каждый коммит и страдай, собственно в чём вопрос-то?

Нет ли третьего варианта, о котором я не знаю?

Сам подумай. Если ты хочешь прочитать из репозитория, придётся её туда закоммитить. Если не хочешь коммитить, генери и не коммить.

Сам подумай.

Ну сижу думаю. Заодно спросил, может кто-то уже придумал.

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

Только что придумал

Нацепляй крюков на прод ветки, которые запрещали бы коммит без инкремента version или как ты там решишь её хранить. И пусть страдают, кто не умеет прекоммит скрипт написать.

Было бы семантическое версионирование, так бы и сделал, чтобы осознанно версионировали. А так перфекционизм не позволяет. Надо автоматизировать.

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

Почему бы не сделать это на стороне сборочной системы, чтобы не зависеть от CI и прочего? Например, для Gradle:

springBoot {
	buildInfo {
		properties {
			additional = [
				'revision': getShortGitRevision()
			]
		}
	}
}

def getShortGitRevision() {
	try {
		return 'git rev-list --count HEAD'.execute().text().trim() + '-' + 
			'git rev-parse --short HEAD'.execute().text.trim()
	} catch (IOException ignored) {
		logger.warn('Git not found.')
		return 'unknown'
	}
}

При вызове вроде:

String.format("Revision: %s", context.getBean(BuildProperties.class).get("revision"))

Это тебе даст строку Revision: 398-798316bf с количеством коммитов на ветке и хешем последнего. И всякие Jenkins’ы пусть занимаются своими делами.

шей номер комита, ну.

Хочу чтобы можно было зачекаутить коммит

это называется tag

всё очень просто

VERSION ?= $(shell git describe –abbrev=7 –long | sed ‘s/^v//g’)

libshit-20201112-gdeadbabe

При чём тут тэг?

git checkout commit-hash>

Нельзя просто взять и обновить мажорный номер версии.

Я смотрю, тут собралась ЭЛИТКА!

И как оно быть ЭЛИТКОЙ?

Расскажите истории успеха. А то читаю говно суржик и понимаю, что код не лучше.

Главное, отвечают тоже УДИВИТЕЛЬНО!

Подумалось, фигню я придумал. Вот новая – вынести файлик с номерами версий в отдельную репу, и комитить инкременченое туда после успешной сборки.

Все нормальные системы сборки берут последний версионный тег, отсчитывают число коммитов от него и собирают лабуду-1.2.3+17. Разизобрети свой велосипед, пока никто не увидел.

Тогда это

Но если так, то на каждый коммит в мастер будет создаваться второй коммит с обновлением номера. Неприятно.

противоречит этому

Чтобы по желанию левой пятки мажорный номер руками обновить.

Ты же не каждый второй коммит обновляешь мажорный номер?

У меня например в репозитории лежит файл с major.minor, при сборке используется еще и BUILD_NUMBER

нормальные системы сборки берут последний версионный тег

Это не работает если(как в данном случае, см. выше) програмцы считают себя недостойными придумывания номеров версий(или наоборот).

И никакая схема версионирования не будет. Номер ревизии SVN, разве что, но с ограничениями и без всех плюсов, кроме упорядоченности.

никакая схема версионирования не будет

Велипедная вариация: объявить версией эН.номерсборки всё, что успешно проходит множество автотестов, изданных до даты летнего сонцестояния еНого года жизни проекта(или по любому другому расписанию, несущественно).

и проверять каждый комит на каждый набор тестов и присваивать ему все номера, если ошибок не нашлось.

Чем не «будет»?

Тем, что это дает лишь упорядоченность сборок.

лишь упорядоченность сборок

Наоборот, оно даёт формально правильное определение соответствия почётному званию «мажорной версии» в семверном смысле – код, проходящий все тесты этой версии поддерживает все известные ранее её ф-ии, т.о. может спокойно рассматриваться исторически очередным минорным релизом оной.

В той же Miranda NG хранят текущую версию, а в процессе сборки делается

# аналог номера коммита в SVN
git rev-list --count HEAD
# хэш коммита
git rev-parse --short HEAD

Из этих трёх значений и собирается версия.

Нет. Интерфейс одними тестами не определишь => номер сборки это всего лишь номер сборки, без плюшек семвера.

У меня цель – хранить версию в гите
номер должен лежать в репозитории
откуда дженкинс должен брать нынешний номер

Оттуда и брать. В чём трабла то?

Ты без дженкинса сначала разберись с версионированием.

Что такое версия в твоем проекте? Значение зашито параметром в коде? semver?

Кто триггерит релиз? Как он узнает какая версия должна быть у этого релиза? Выкатывается каждый коммит или только выборочные версии?

Если выкатывается каждый коммит то у тебя понятия версии как такового нет, есть git sha коммита и есть номер сборки.

Если выкатывается выборочная версия, то во-первых её не обязательно хранить текстом в файле в гите, можно использовать git tag и вешать автоматизацию на событие создания нового тега. Тогда менять значение не нужно. Процесс релиза начинается с простановки тега вручную майнтейнером репозитория.

Если выкатывается выборочная версия и она же должна лежать в файле в гите, то следующий вопрос: между двумя последовательными версиями 1.2.3 и 1.2.4, пока код находится в разработке, а не в релизе, какое значение версии должно быть в гите?

И меня загрузила. Нахрена? Сказала б что просто — хочешь поменять версию: поменяй её в файле, который инклюдится, и делов.