Каковы правильные вызовы Travis API (или методы библиотеки), чтобы сначала запустить и просмотреть сборку, а затем получить ее статус и журнал сборки? - PullRequest
Новая
       28

Каковы правильные вызовы Travis API (или методы библиотеки), чтобы сначала запустить и просмотреть сборку, а затем получить ее статус и журнал сборки?

0 голосов
/ 09 декабря 2018

В одном из моих приложений я хочу запустить сборку Travis CI, «наблюдать» за сборкой, как она запланирована, запускаться и заканчиваться, затем извлекать окончательное состояние сборки и журнал сборки для вывода его в мое приложение.

Я начал с , вызвав сборку с API , что дает мне Request и его request.id.Это отлично работает.

  • Затем я могу получить этот Request, который включает Request.state и встроенный Build и его Build.id вместе с Build.state, используя /repo/.../request/#id конечная точка .
  • Затем я мог бы начать опрос /build/#id конечная точка для отслеживания состояния каждую секунду.
  • Как только сборка будет завершенаЯ могу использовать Job, который является частью Build (при запросе от /build/#id), чтобы загрузить журнал из /job/#id/log и отобразить его в моем приложении.

Все это звучит довольно неэффективно.

Есть ли лучший способ добиться этого?
Есть ли "более быстрый" способ (= меньше запросов) от создания request до log?
Можно ли как-нибудь избежать ручного опроса?

1 Ответ

0 голосов
/ 09 декабря 2018

Я буду использовать этот ответ для документирования своего собственного исследования, которое может помочь решить эту проблему:

  1. API-интерфейс Travis CI поддерживает активную загрузку через ?include.Используя это, я уже могу получить Job.id в ответе Request через расширенные Build объекты: ?include=request.builds - мне не нужно делать еще один запрос к конечной точке build для Job.id.Но так как мне нужно опросить изменения статуса, это не очень помогает.

  2. Как @ Maël Pedretti предложил в комментариях, Travis поддерживает уведомления webhook . представленный объект содержит id, то есть Build.id, так что это может заменить часть опроса, которую я описал выше.Поскольку мое приложение работает не только на одном сервере, который можно настроить как URL-адрес webhook, мне нужен серверный компонент с состоянием, который мое приложение могло бы опрашивать или прослушивать.Так что просто торговля лошадью: /

...