Hudson Cli, чтобы ждать незавершенных сборок - PullRequest
0 голосов
/ 09 ноября 2010

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

Как я могу (после пометки его в автономном режиме) ждать, пока узел завершит свою текущую работу (и)?

Ответы [ 2 ]

1 голос
/ 09 ноября 2010

Вы можете узнать, выполняется ли в данный момент задание, с помощью API удаленного доступа Hudson (также см. Документацию по адресу http://your-hudson-url/api). В зависимости от ваших предпочтений, API может возвращать XML, JSON или читаемый Python формат.

В частности, вы должны посмотреть на API для работы. Лучший способ проверить, что доступно в API - посмотреть на ваш сервер, http://your-hudson-url/job/<job name>/api/xml. Каждое задание имеет список сборок (и результатов), которые отслеживает Хадсон. Если сборка выполняется, элемент build / building будет содержать true.

Вот некоторые примеры вывода XML из моей тестовой сборки, url http://localhost:8080/job/Plotting build/api/xml?depth=1 (обратите внимание, что параметр глубины, установленный в 1, дает вам больше подробностей, чем по умолчанию):

  <freeStyleProject>
  <action/>
  <description>An example of the plot plugin</description>
  <displayName>Plotting build</displayName>
  <name>Plotting build</name>
  <url>http://localhost:8080/job/Plotting%20build/</url>
  <buildable>true</buildable>
  <build>
    <action>
      <cause>
        <shortDescription>Started by user test</shortDescription>
        <userName>test</userName>
      </cause>
    </action>
    <building>false</building>
    <duration>30291</duration>
    <fullDisplayName>Plotting build #14</fullDisplayName>
    <id>2010-10-29_16-14-02</id>
    <keepLog>false</keepLog>
    <number>14</number>
    <result>SUCCESS</result>
    <timestamp>1288394042180</timestamp>
    <url>http://localhost:8080/job/Plotting%20build/14/</url>
    <builtOn/>
    <changeSet/>
  </build>
  <build>
  ...

Я не знаю, имеет ли какое-либо влияние отключение узлов. Я предполагаю, что, пока Хадсон знает, что сборка выполняется, API будет возвращать правильную информацию, и вы можете периодически запрашивать, завершена ли самая последняя сборка.


Обновление : В качестве альтернативы вы можете использовать API для запроса узлов, чтобы определить, не заняты ли они. Однако, насколько я могу судить, Hudson API не показывает, какое задание выполняется в выводе запроса узла.

Пример вывода из http://localhost:8080/computer/(master)/api/xml?depth=1

<masterComputer>
  <displayName>master</displayName>
  <executor>
    <idle>true</idle>
    <likelyStuck>false</likelyStuck>
    <number>0</number>
    <progress>-1</progress>
  </executor>
  ...
  <idle>true</idle>
  ...

Элемент computer / idle равен false, если задание выполняется. На момент написания этой статьи существует ошибка Гудзона , которая приводит к неверному ответу, если вы запрашиваете depth=1 во время выполнения задания (хотя глубина по умолчанию покажет, свободен ли узел).

Используя API узла, вы можете перевести узел в автономный режим (и снова в оперативный режим?) Как часть вашего сценария развертывания.

0 голосов
/ 11 сентября 2012

Если ваш сценарий является локальным для компьютера, я предлагаю вам использовать более неэффективный для полосы пропускания способ обработки.

Используя @Dave_Bacher в качестве примера, я бы взаимодействовал с JSON-версией API, выполняя URL-адрес примерно так ...

http://localhost:8080/job/Plotting build/api/json?depth=1&tree=builds[building,number]

Тогда все, что вам нужно сделать, это быстро пройти через JSON, найти вашу сборку, определить, является ли она build = false или true, и вуаля.

Это уменьшило время выполнения моего скрипта с 10,5 с до менее секунды.

...