Проект «SnakeProject» Михаила КозловаРегистрация

Навигация
⇒FreeBSD and Nix⇒

⇐CISCO
⇐Voice(Asterisk\Cisco)
⇐Microsoft
⇐Powershell
⇐Python
⇐SQL\T-SQL
⇐1С
⇐Общая
⇐WEB Разработка
⇐ORACLE SQL \ JAVA
⇐Мото

FreeBSD: Jenkins и Git


 

FreeBSD: Jenkins и Git


Как установить Git в FreeBSD и завести проект, сделать в нем изменения и т.п. описывал тут:
http://snakeproject.ru/rubric/article.php?art=freebsd_git_gitolite_09.2018

 

Установка Jenkins:
make -C /usr/ports/devel/jenkins make install clean
или
pkg install -y jenkins


Автозагрузка:
echo 'jenkins_enable="YES"' >> /etc/rc.conf


На каком порту запустится:
/usr/local/etc/rc.d/jenkins
: ${jenkins_args="--webroot=${jenkins_home}/war --httpPort=8180 --prefix=/jenkins"}


Стартуем:
/usr/local/etc/rc.d/jenkins start
/usr/local/etc/rc.d/jenkins status


Заходим и первоначально настраиваем:
http://localhost:8180/jenkins/

Если выбирали кастом устанвку, то не забудьте доставить плагины для 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, ...


refs/heads/<branchName>
Отслеживает/проверяет указанную ветку
Например: refs/heads/master, refs/heads/feature1/master,...


<remoteRepoName>/<branchName>
Отслеживает/проверяет указанную ветку.
Если неоднозначно, берется первый результат, который не обязательно является ожидаемым
Лучше использовать refs/heads/<branchName>
Например: origin/master


remotes/<remoteRepoName>/<branchName>
Отслеживает / проверяет указанную ветку.
Например: remotes/origin/master


refs/remotes/<remoteRepoName>/<branchName>
Отслеживает / проверяет указанную ветку.
Например: refs/remotes/origin/master


<tagName>
Это не работает, так как тег не будет распознан как тег
Вместо этого используйте refs/tags/<tagName>
Например: git-2.3.0


refs/tags/<tagName>
Отслеживает / проверяет указанный тег
Например: refs/tags/git-2.3.0 или */tags/1.0.* или */tags/1.1.* или */tags/proj/*


<commitId>
Проверяет указанный коммит
Например: 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...


${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
Результат: задание отработало по плану

 

Удаление тегов:

Удалить удаленный тег:
git push origin :refs/tags/v1.1-12-release
git push origin :refs/tags/v1.1-12

Удалить локально тег:
git tag -d v1.1-12-release
git tag -d v1.1-12


Удалить все удаленные теги:
git tag -l | xargs -n 1 git push --delete origin


Удалить все локальные теги:
git tag -l | xargs git tag -d


Если возникла при удалении ошибка типа: git push origin DENIED by fallthru, hook declined: gitolite
Добавьте пользователю права - RW+ в gitolite

Пример gitolite.conf:
repo @test-repos
    RW+ refs/tags = @gitolite-admins
    RW+           = @progger-group
    R             = @user-group

 

 
 
 
 
 
 

Комментарии пользователей

Эту новость ещё не комментировалиНаписать комментарий
Анонимам нельзя оставоять комментарии, зарегистрируйтесь!

© Snakeproject.ru создан в 2013 году. При копировании материала с сайта - оставьте ссылку.


Яндекс.Метрика

Goon Каталог сайтов Рейтинг@Mail.ru