Если выбирали кастом устанвку, то не забудьте доставить плагины для Git В установке по дефолту они ставятся
Далее задача 1, заставить Jenkins реагировать на изменение в проекте
Создаем задачу (item) со свободной конфигурацией
Управление исходным кодом - Git
Repositories - Repository URL (как в команде git clone) - Your_Username@Your_Git_Server:Your_Project_Name
Credentials (два варианта, можно логин с паролем или логин с приватным ssh ключом пользователя Git) - Your_Username
Триггеры сборки - Опрашивать SCM об изменениях (как в cron, например раз в три минуты) - H/3 * * * *
Сборка - Выполнить команду shell - Команда - echo 'test' > /tmp/test_jenkins
Сохранить
Все, изменяем что-то в нашем проекте, git add, commit, push В итоге спустя 3 минуты задача отработает т.к. увидит изменения в проекте
Далее задача 2, заставить Jenkins реагировать на теги в проекте
Тэг по сути - информационная метка - срез
Т.е. сделали например git push и делаем тэг на состояние репозитория
Я смог сделать это с помощью параметра "ветки для сборки" (branches to build): Branch Specifier (blank for 'any'): tags/[tag-name]
Укажите ветви, если вы хотите отслеживать конкретную ветку в хранилище.
Если оставить это поле пустым, все ветви будут проверены на наличие изменений и построены
Самый безопасный способ - использовать синтаксис refs/heads/<branchName>
Таким образом, ожидаемая ветвь однозначна.
Если вы используете спецификатор ветви с подстановочными знаками, с косой чертой (например, release/)
Вам нужно будет указать репозиторий источника в именах ветвей, чтобы убедиться, что изменения подобраны
пример: origin/release/
Возможные варианты:
<BranchName>
Отслеживает / проверяет указанную ветку. Если неоднозначно, берется первый результат, который не обязательно является ожидаемым
Лучше использовать refs /heads/<branchName> Например: мастер, feature1, ...
<remoteRepoName>/<branchName>
Отслеживает/проверяет указанную ветку.
Если неоднозначно, берется первый результат, который не обязательно является ожидаемым
Лучше использовать refs/heads/<branchName> Например: origin/master
${ENV_VARIABLE}
Также возможно использование переменных окружения
В этом случае переменные оцениваются, и результат используется, как описано выше Например: ${TREEISH}, refs/tags/${TAGNAME},...
:<regular expression> Примеры:
:^(?!(origin/prefix)).* соответствует: origin или origin/master или origin/feature не соответствует: origin/prefix или origin/prefix_123 или origin/prefix-abc
:origin/release-\d{8} соответствует: origin/release-20150101 не соответствует: origin/release-2015010 или origin/release-201501011 или origin/release-20150101-something
:^(?!origin/master$|origin/develop$).* соответствует: origin/branch1 или origin/branch-2 или origin/master123 или origin/develop-123 не соответствует: origin/master или origin/develop
Итак, в задаче Дженкинса:
Управление исходным кодом - Git - Branches to build - Branch Specifier (blank for 'any')
Заменим дефолт:
*/master на:
refs/tags/*release
Сохраним
Перейдите в ваш репозиторий
Посмотреть все метки - git tag (в данный момент мы их еще не делали)
Поиск по шаблону можно сделать так: git tag -l 'v1.1.12*'
Создадим метку, есть два типа меток:
Легковесная - простой указатель на указанный коммит (контрольная сумма коммита, сохраненная в файле)
Пример создания:
git tag v1.1-12-release Информация по метке:
git show v1.1-12-release
Аннотированная:
Хранится в базе данных Git как полноценный объект
Имеет контрольную сумму, имя автора метки, email, дату, комментарий
Может быть подписана и проверена GNU Privacy Guard (GPG)
Пример создания (опция -a):
git tag -a v1.1-12 -m 'working release 1.1-12' Информация по метке:
git show v1.1-12
По дефолту git push не отправляет метки на удаленный сервер Отправка осуществляется так: git push origin [tag_name] Пример: git push origin v1.1-12
Отправка множества меток сразу: git push origin --tags
Проверяем для Branch Specifier (blank for 'any') - refs/tags/*release!
1. Делаем изменения в репозитории и делаем эдд, коммит и пуш, метку не выставляем и не отправляем Результат: нет эффекта
2. Делаем аннотированную метку git tag -a v1.1-12 -m 'working release 1.1-12' и отправляем
git tag -a v1.1-12 -m 'working release 1.1-12'
git push origin v1.1-12 Результат: нет эффекта
3. Делаем легковесную метку git tag v1.1-12-release и отправляем
git tag v1.1-12-release
git push origin v1.1-12-release Результат: задание отработало по плану
Код обмена баннерами