Как предотвратить выполнение определенных заданий Дженкинса одновременно?

У меня есть несколько заданий, в которых используется общий ресурс (база данных), который иногда может привести к сбою сбоев в (редком) событии, когда рабочие задания запускаются одновременно.

Если заданы задания от A до E, например, есть ли способ указать, что A и C никогда не должны запускаться одновременно?

Кроме вышеупомянутого ресурса, сборки не зависят друг от друга (например, в отношении восходящего/нисходящего потока).

Метод "грубой силы" ограничивал бы число исполнителей одним, но это, очевидно, было бы менее идеальным, если бы большинство заданий могли выполняться одновременно, и на сервере сборки не было недостатка вычислительных ресурсов.

Ответы

Ответ 1

В настоящее время существует 2 способа сделать это:

Используйте плагин Блокировать параллельные сборки.
Настройте эти задания для работы на ведомом, имеющем только 1 исполнитель.

Ответ 2

Плагин Locks and Latches здесь должен помочь.

Этот вопрос, вероятно, является обманом Как я могу гарантировать, что только одна из определенной категории заданий запускается сразу в Хадсоне?

Ответ 3

Посмотрите Диспетчер внешних ресурсов Плагин Jenkins, который был впервые опубликован в ноябре 2012 года. Этот (относительно) новый плагин, похоже, точно крышка это кейс.

Ответ 4

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

Lockable Resources Plugin позволяет определить блокируемые ресурсы, которые могут использоваться сборками. Если для сборки требуется ресурс, он блокирует. Если для второй сборки требуется один и тот же ресурс (который уже заблокирован), он будет поставлен в очередь, чтобы ресурс был свободным.

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

В отличие от Locks and Latches Plugin, упомянутого в ответах с 2012 года, этот пакет, похоже, в настоящее время поддерживается (в настоящее время ~ 2016).

Ответ 5

N.B. вам не нужно физическое или виртуальное оборудование для ведомого / node, вы можете настроить "ведомые", которые запускаются на главном сервере.

Управление Jenkins > Управление узлами > Новый node

и создайте "немых подчиненных", каждый со своим корневым каталогом.

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

Возможно, у вас есть, скажем...

db - только один исполнитель в вашем случае. компилировать - ограничение в соответствии с оборудованием или # процессоров. скрипты - есть много исполнителей для всех тех маленьких заданий, которые Дженкинс умеет делать.

Ответ 6

Старый вопрос, и будет ли это работать для вашего приложения, я не могу быть уверен, так как вы не указали детали своего приложения. Тем не менее, я хотел добавить способ, которым я занимался этим в нашем тестовом наборе приложений Rails.

Конфигурация нашей базы данных приложений (database.yml) не находится в исходном репозитории. Вместо этого он живет в /var/lib/configs/uniquing_database.yml на виртуальной машине, которая запускает наш экземпляр Jenkins.

Один из шагов нашего процесса сборки заключается в копировании этого файла конфигурации в рабочую область проекта:

cp /var/lib/jenkins/configs/myapp_unique_database.yml config/database.yml

и эта конфигурация принимает рабочее пространство и информацию о количестве номеров, открытую для среды Jenkins, для создания уникальной базы данных для этого задания и конкретного выполнения:

test:
  adapter: postgresql
  encoding: unicode
  host: 127.0.0.1
  port: 5432
  database: myapp_test<%= ENV['JOB_NAME'].split('/').last %><%= ENV['BUILD_NUMBER'] %>

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

RAILS_ENV=test bundle exec rake db:drop