Post Commit Hook - Jenkins: Начиная работу после простоя Jenkins

Question

Мы внедрили Post Commit Hook, который начинает наши работы в Jenkins. Наше вдохновение таково: Trouble with SVN post-commit and Jenkins

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

Мой вопрос сейчас: Что вы будете делать, если сервер Jenkins не работает? Конец принимается в любом случае, но задание не запускается, поскольку сервер Jenkins не работает ... Как вы гарантируете, что задания будут запущены при повторном запуске сервера?

Answer 1

Если вы обеспокоены пропущенным фиксацией, вам необходимо буферизовать уведомления Jenkins. Одним из возможных сценариев будет следующий:

Запишите информацию в файл (базу данных), когда Jenkins недоступен. Вам нужен второй процесс, который периодически читает файл (БД) и подталкивает информацию Дженкинсу, когда Дженкинс доступен.

Совершенно другой вариант - игнорировать случай, когда Дженкинс недоступен. Когда есть частые изменения в источнике, тогда следующая сборка будет запущена в ближайшее время. Для рабочих мест, где есть только редкие изменения, вы можете использовать Startup Trigger Plugin. Вы также можете запустить задание при запуске, которое считывает файлы (db) из предыдущего примера.

---

В общем, просто пройти через Jenkins Plugin list и пусть ваше воображение идти дикой природы с тем, что плагины могут сделать для вас. Вы можете придумать очень творческие решения.

Answer 2

Jenkins проведет опрос вашего исходного хранилища до одного раза в минуту, чтобы узнать, нужно ли что-то строить.

Когда мы использовали CVS, я использовал пост-фиксацию для принудительной сборки Subversion, потому что опрос репозитория CVS, чтобы увидеть, произошло ли изменение, было длительной и интенсивной с процессором. Если вы выполняете дюжину или более проектов в Jenkins с помощью CVS, вы замедлите Jenkins и ваше CVS-репо на сканирование. Использование триггера post-commit было единственным способом. Тем не менее, одна из проблем, с которыми мы столкнулись, заключается в том, что если Дженкинс снизился, это не приведет к отсутствующим сборкам.

Когда мы переехали в Subversion, я просто задал Дженкинсу опрос наших репозиториев Subversion каждую минуту. Поиск того, произошло ли изменение в Subversion, довольно быстро и занимает немного ресурсов. Если сервер Jenkins не работает, Дженкинс немедленно опросит различные проекты Subversion и начнет строить практически там, где он остановился.

Есть несколько минусов с этим поведением, и причиной, почему некоторые сайты не позволяют Дженкинс опрашивать репозиторий:

• Это может занять до 59 секунд для сборки произойдет. Если сборка занимает две минуты, разработчик может ждать на 50% дольше, чтобы узнать, было ли их изменение успешным.
• Если два разработчика совершают фиксацию в течение одной минуты, оба их изменения будут построены. Если произойдет сбой, мы не сможем сказать, какое изменение вызвало проблему.

Для меня это незначительные проблемы, и мне нравится тот факт, что Дженкинс позаботится о себе, если я не буду беспокоиться об этом.Однако, если вам нужно создать триггер Subversion в Jenkins, вы можете сделать это с помощью коммита post-commit, выдающего команду сборки, но, как вы выяснили, если Дженкинс не работает, он не узнает, что он должен делать сборку ,

Один из способов сделать это, чтобы Дженкинс делал опрос и использовал крюк после фиксации, чтобы вызвать сборку Дженкинса. Там есть file system SCM plugin, который будет опробовать файл или каталог, а триггер сработает. Существует также command line interface Дженкинсу. Вы можете объединить их в свой крюк после фиксации.

Используйте интерфейс командной строки, чтобы увидеть, работает ли Jenkins. Если это так, вы можете запустить сборку через URL-адрес, как обычно. Если Jenkins не работает и обновляется, обновите файл опроса.

Jenkins может опробовать этот файл каждые 5 минут или около того (не нужно запускать триггер), и если он обнаружит, что этот файл был изменен, он автоматически выполнит новую сборку. Таким образом, если Дженкинс не работает, вы можете использовать механизм опроса в качестве резервной копии.

Answer 3

Наше решение вопроса:

Вместо того, чтобы пост-совершать вызов крюк сервер Дженкинс напрямую, мы называем нашим центральным приложения качества (контроль все наши серверы Дженкинс, рабочие места и т.д.). Это приложение затем нажимает сборку на соответствующий сервер Jenkins. Если сервер Jenkins не работает - приложение снова пытается выполнить попытку позже.