Как остановить сборку, но не строить цепочку, если артефакты идентичны

У меня есть проблема с планом сборки в цепочке сборки, которая меня очень беспокоит.

У меня есть простая цепочка сборки A -> B, где

  • A работает очень быстро (менее минуты) — в основном он извлекает базу данных из производственной системы. Невозможно определить, будет ли полученный артефакт идентичен предыдущему результату до завершения обработки. В настоящее время время сборки запланировано.
  • B очень медленный (5-6 часов) — он объединяет вывод из A плюс ряд других источников в большое количество артефактов. В настоящее время он имеет зависимость моментального снимка от A, а также зависимость от других источников.

Я хотел бы избежать запуска B без необходимости, т.е. если какие-либо входные данные для B изменились, но как мне это сделать?

Я могу потерпеть неудачу/отменить A, если он обнаружит, что результаты не изменились, но это приведет к «сбою зависимости моментального снимка» для B, поэтому, если какие-либо другие другие источники ввода для B изменятся, он не будет восстанавливать результаты...

Есть ли способ остановить или прервать сборку A, чтобы сборка B не запускалась?

EDIT: у меня (возможно) есть идея: я мог бы позволить A проверить полученный артефакт в SCM — если он отличается от предыдущей версии — и позволить этому управлять триггер B, у которого уже есть ряд других источников в SCM. Насколько я понимаю, это не будет частью той же цепочки сборки, но это следующая лучшая вещь...


teamcity teamcity-9.0
person Tonny Madsen    schedule 29.09.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я так не думаю. Цепочки сборки в TeamCity статичны.

Есть два возможных обходных пути

  1. Write a plug-in to handle this case. It would be a server-side plugin that kicks in on the buildTypeAddedToQueue(SQueuedBuild queuedBuild) event, when B is queued. It would do some looking around (comparing artifacts) and remove B from the queue immediately.
    • I believe this will behave as if B were queued and then de-queued by a user. I.e. it's not as hacky as it seems - removing builds from queue is a supported TC operation.
    • Это может оказаться более трудоемким, чем вы хотели бы...
  2. Handle this in B.
    • This is probably much simpler but I'm assuming you want to avoid this.

Я думаю, что в идеале вы хотели бы справиться с этим в A, поэтому № 2 не вариант. # 1 подходит близко, хотя, конечно, это немного сложнее.

person sferencik    schedule 29.09.2015

arrow_upward
0
arrow_downward

Я предполагаю, что следует пропустить перестройку A и использовать последнюю, если новая потенциальная сборка A будет идентична некоторым из недавних. Например, запрос зависимой сборки A с той же версией VCS и с теми же настройками не должен запускать сборку снова.

person Alexander Goncharenko    schedule 29.09.2015
comment
У вас есть что-то, что может помочь определить, изменились ли ваши данные БД? Может быть, метка времени последнего обновления или просто случайный идентификатор, генерируемый каждый раз при изменении данных. Если это так, вы можете сделать следующее. Удалите триггер расписания для вашей сборки A. Введите другую запланированную сборку, которая будет проверять, следует ли перестроить A, и запускать ее соответствующим образом. Таким образом, вы сохраните запланированные обновления, но A будет обновляться только тогда, когда это действительно необходимо. Но, пожалуйста, внимательно сверьтесь с документами TC, чтобы убедиться, что цепочка настраивается, чтобы не перестраивать A каждый раз, когда запрашивается B. - person Alexander Goncharenko; 29.09.2015