Kibana: [ОБСУДИТЬ] Запретить elasticmachine сообщать о результатах сборки в PR

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

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

Пожалуйста, оставьте :+1:, если ваш ежедневный рабочий процесс зависит от получения уведомлений по электронной почте о статусе сборки.

Я так обеспокоен этой проблемой, что определенно полагаюсь на уведомления по электронной почте, но я ненавижу беспорядок, который оставляют все эти комментарии! Мне также нравится, что это простой прямой путь к ci. Я часто щелкаю ссылку из электронной почты на своем телефоне, чтобы отправить меня прямо на ci, а не на github.

Есть ли способ, чтобы эластичная машина делала только один комментарий и просто редактировала его во время работы? Итак, вместо связки что-то вроде:

  [timestamp] ci failed - [link]
  [timestamp] ci failed - [link] 
  [timestamp] ci passed - [link]

хотя... я думаю, что обновление существующего комментария не отправляет электронное письмо...

Другим преимуществом этой истории является то, что иногда при ненадежном тестовом расследовании приятно иметь все прошлые ссылки или даже просто исследование ошибки ... это как, ах, подождите, почему предыдущая фиксация не удалась? И я могу посмотреть его по ссылке и сравнить с текущими результатами запуска ci.

Лично я им пользуюсь. Я не против увидеть их в пиаре

Я бы хотел, чтобы это произошло, но мы видели некоторые проблемы со стабильностью с проверками GitHub. Нередки случаи, когда запрос Check API терпит неудачу и, следовательно, сообщает о неудачном запуске CI. Мы пытаемся улучшить нашу логику повторных попыток, что не должно быть сложно, но я не проделал работу, чтобы убедиться, что она работает правильно. Я думаю, я думаю, что это может быть _просто_ немного рано для этого.

Кроме того, поздравляю всех, кто может сделать спам на github читабельным. ;-)

Возможно, лучшим решением было бы отключить комментарии GitHub, оставленные рудиментарным плагином Jenkins, и вместо этого отправлять комментарии от бота, который удаляет и резюмирует старые комментарии. Может быть, что-то вроде проблемы команды внутренней инфраструктуры 6274.

Редактировать: Удаление собственных комментариев пользователей не оставляет записей в истории, поэтому это будет означать, что есть один комментарий, а новые комментарии будут вызывать электронные письма.

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

Другим преимуществом этой истории является то, что иногда при ненадежном тестовом расследовании приятно иметь все прошлые ссылки или даже просто исследование ошибки ... это как, о, подождите, почему предыдущая фиксация не удалась? И я могу посмотреть его по ссылке и сравнить с текущими результатами запуска ci.

Флажки рядом с каждым коммитом в PR дают краткую визуальную историю сбоев сборки:

Похоже, что есть ряд людей, которые хотят получать уведомления о сборке. Использование комментариев Github -> Электронная почта — это простая система, но для меня было бы полезнее получать уведомления через slack. Не знаю, возможно ли технически сопоставить имена пользователей github со слабыми именами пользователей.

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

Я думаю, что предложение @spalger — лучшее из обоих миров: все по-прежнему получают уведомление по электронной почте, потому что elasticmachine будет публиковать новый комментарий к каждой сборке, но история разговоров не загромождена кучей устаревших сообщений о статусе сборки.