Предполагается, что вы пытаетесь «вернуться назад», то есть взять хранилище, которое, как вы обнаруживаете, находится в отдельном режиме HEAD, и угадать, как оно туда попало. Первая проблема заключается в том, что он может вообще туда не попасть через git checkout <tag-name>. Во-вторых, даже если это произойдет - в этом случае git describe --tags --abbrev=0 покажет единицу - то, что показывает git describe, может не совпадать с тем, которое фактически использовалось для выполнения проверки.
Причиной этого является то, что теги Git являются в первую очередь механизмами преобразования понятных человеку имен в хэш-идентификаторы. Может быть несколько имен для любого заданного хеш-идентификатора коммита, и если это так, git describe просто выберет одно и будет его использовать. В версиях Git 1.7.10 и более поздних , git tag --points-at HEAD будет перечислять все теги, которые указывают на текущий коммит; затем вы можете попытаться угадать, какой из них, если таковой был, использовался.
Кроме того, вы можете использовать реплог репозитория HEAD, в котором будет строка, содержащая имя тега, если тег использовался. Команда git status в современном Git делает это и печатает HEAD detached at <em>tag-name</em> для этого случая. Это более надежно, чем вывод git describe, при условии в рассматриваемом хранилище включены reflogs и имеется запись reflog. Ни один из этих двух вариантов - что reflogs включены, и если да, то что есть подходящая запись - не гарантируется. Таким образом, методы описания и указания более надежны.
Другой способ взглянуть на это предполагает, что вы хотите «идти вперед»: что Дженкинс сам выполнил операцию git checkout. В этом случае все, что вам нужно сделать, - это убедить Дженкинса выдать вам имя тега, которое оно передало git checkout.
Там должен быть способ сделать это. Действительно, должно быть тем, что вы уже пробовали, т.е. использовать env.TAG_NAME. Это, по-видимому, заявлено на работу сейчас . Возможно, обновление Дженкинса поможет.
Я был бы рад исправить мои утверждения о том, что документация Jenkins отстой * большое время ужасно неадекватна, поскольку нашла некоторую полную, исчерпывающую и точную документацию, в которой указывается, какие версии Jenkins поддерживают какие особенности, какие стадии конвейера выполняются параллельно, а какие нет, и так далее, но я так и не нашел. (Git, по крайней мере, на немного лучше в том смысле, что можно искать в заметках о выпуске , чтобы узнать, когда были добавлены определенные функции, но и здесь все может быть намного лучше. Сравните с документацией Python, которая пытается вызвать, когда, в частности, какая-то функция, такая как pathlib , была новой.)