Настройка триггеров рабочих процессов

Триггеры - это мощный инструмент для синхронизации  задач пользователей  JIRA с информацией выбранных ими  инструментах разработки (FishEye / Crucible, Bitbucket и GitHub). Вместо того, чтобы полагаться на разработчиков, которые  вручную обновляют статус проблем после фиксирования кода, завершения обзоров, создания ветвей и т. д., пользователи  могут самостоятельно настроить триггеры в своем рабочем процессе для автоматического перехода к задачам, возникающим при возникновении этих событий в ваших инструментах разработки. Например, вы можете настроить триггер для автоматической передачи проблемы с «Сделать» (To Do) на «В разработке» (In Progress), когда создается ветка.

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

Совет. Если вы интегрируете JIRA с инструментами разработки указанными выше, вы дополнительно включите ряд других функций. К ним относятся информация о разработке, отображаемая по задачам, и возможность создания ветви при начале работы над задачей. Подробную информацию см. в разделе «Оптимизация вашей разработки с JIRA».

Руководство: настройка триггеров

В этом примере вы будете настраивать рабочий процесс JIRA с помощью триггеров. В конце этого раздела вы узнаете, как настроить триггеры и как выглядит типичный рабочий процесс разработки с триггерами.

Введение

Снимок экрана и таблица ниже показывают рабочий процесс и триггеры, аналогичные тем, что вы будете настраивать. Они отражают типичные взаимодействия между JIRA и инструментами разработки в жизненном цикле разработки программного обеспечения. В этом примере используются JIRA (6.3.4), сервер Bitbucket (ранее Stash) и FishEye / Crucible (3.5.2), но вы можете настроить что-то подобное с помощью любого из поддерживаемых инструментов разработки.

Переход

Триггеры

Начало прогресса

(«Сделать» → «В разработке»)

 

Создана ветвь (сервер Bitbucket)

Создана фиксация кода (сервер Bitbucket)

Начало  обзора(«В разработке» → «В обзоре»)

Переместите созданный запрос (request) (Сервер Bitbucket)

Переместите вновь открытый запрос (request) (Сервер Bitbucket)

Начатый Обзор (Crucible)

Перезапуск

разработки(В обзоре → В процессе)

Переместите отклоненный запрос(request) (Сервер Bitbucket)

Отклоненный Обзор (Crucible)

Оставленный Обзор (Crucible)

Сделано

(«В обзоре» → «Сделано

»)

Переместите объединенный запрос (Сервер Bitbucket)

Закрытый обзор (Crucible)

 

Шаг 1. Создание / редактирование рабочего процесса

Самый простой способ создать рабочий процесс разработки программного обеспечения - создать новый проект, выбрав тип проекта Software Development. Это создаст ваш новый проект с рабочим процессом разработки программного обеспечения, который идентичен показанному выше.

Если у вас уже есть аналогичный рабочий процесс, перейдите к нему и отредактируйте его:

консоль администрирования JIRA> «Задачи»  (Issues)> «Рабочие процессы» (Workflows)> «Изменить» (Edit)

Шаг 2. Добавление триггера  к переходу

Начнем с добавления триггера «Создана фиксация кода» (Commit created) к переходу «Начало прогресса» (Start progress).

Убедитесь, что вы редактируете ( а не просматриваете) рабочий процесс.

  1. Выберите переход «Начальный прогресс» (Start progress) в рабочем процессе, т. е. строку «Сделать» (To Do) в «В разработке» (In Progress). Справа отобразится панель с указанием деталей перехода.

Связанная тема: Почему вы не должны настраивать триггеры для глобальных переходов

  1. Нажмите «Триггеры» (Triggers ) на панели. Экран «Переход: начало прогресса» будет отображаться (View Details) на вкладке «Триггеры».

  1. Нажмите «Добавить триггер» (Add trigger), затем выберите «Зафиксировать код» (Commit created), в появившемся диалоговом окне. Появится окно диагностики - вы заметите, что триггер будет добавлен для всех инструментов разработки, к которым подключен JIRA (сервер Bitbucket и FishEye / Crucible в этом примере).

 

Связанная тема: Как включить различные события для триггеров

  1. Нажмите «Добавить триггер» (Add trigger), чтобы добавить триггер. Он появится в списке внизу вкладки «Триггеры». Вы можете проверить, работает ли он, нажав «Просмотреть детали» (View Details).

Это оно! Не забудьте опубликовать черновик рабочего процесса.

Шаг 3. Протестируйте триггер

Теперь, когда вы добавили триггер «Создана  фиксация кода» (Commit created) к переходу «Начало прогресса» (Start progress), давайте проверим его, сделав фиксацию.

  1. Создайте задачу в проекте JIRA. Этот проект должен использовать рабочий процесс, который вы только что отредактировали.

Статус вашей новой задачи должен быть «Сделать» (To Do). Обратите внимание на ключ задачи, так как вам понадобится он для следующего шага.

  1. Зафиксируйте некоторый код в репозиторий сервера Bitbucket. Вы можете совершить что угодно, однако вам нужно будет включить ключ задачи в сообщение фиксации.

В этом примере ключом задачи является TIS-1, на который ссылается сообщение фиксации об ошибке, показанное на скриншоте.

Связанный раздел: Ссылка на задачу JIRA в фиксации, ветви, перемещении запроса(request), или обзоре

  1. Еще раз проверьте свою задачу в JIRA. Статус должен был измениться с «Сделать» (To Do) на «В разработке» (In Progress). Если вы перейдете на вкладку «История» (History) или вкладку «Активность» (Activity), вы увидите автоматический переход, который изменил статус проблемы.

Связанные темы: как пользователь сопоставляется с инструментом разработки JIRA;

Обработка событий и ограничения событий;

Как триггеры относятся к другим операциям / ограничениям рабочего процесса

Шаг 4. Добавление остальных триггеров

Теперь, когда вы добавили и протестировали триггер, выполните один и тот же процесс, чтобы добавить остальные триггеры в список выше.

Не хотите все это уладить? Хорошие новости! Вы можете загрузить аналогичный рабочий процесс (предварительно сконфигурированный с помощью триггеров) из Atlassian Marketplace: загрузите «Рабочий процесс разработки с  триггерами» (Development Workflow with Triggers).

Поздравляем! Теперь вы создали рабочий процесс с триггерами.

  • Если у вас возникли проблемы с настройкой триггера или его работой, проверьте раздел «Устранение неполадок» ниже.
  • Если вы хотите узнать больше о том, как работают триггеры, см. раздел «Понимание триггеров» ниже.

Понимание триггеров

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

Триггерные события  

События (например, Создана фиксация кода) становятся доступными для триггеров путем интеграции JIRA с конкретными инструментами разработки. В приведенной ниже таблице перечислены события, которые включены для каждого инструмента разработки.

Инструмент разработки

Bitbucket, GitHub, GitHub Enterprise

Crucible

FishEye

События

  •  Переместите созданный запрос(request )
  • Переместите объединенный запрос(request )
  • Переместите отклоненную запрос(request ) (Bitbucket только)
  • Переместите вновь открытый запрос (request ) (Сервер Bitbucket только)
  • Созданная фиксация кода
  • Созданная ветвь
  •  начало обзора
  •  Представлено на утверждение
  • Обзор отклонен
  • Обзор оставляется
  • Обзор закрыт
  •  Полученный обзор  в итоге
  • Созданная фиксация кода
  • Созданная ветвь

 

(ИНФО) Существует известная задача, когда событие «Ветвь создана» (Branch created) не поддерживается для GitHub, который отслеживается в JSWSERVER-14473 - реализует функцию «Создать ветвь» (Create Branch) в подключаемом модуле DVCS для интеграции Github CLOSED - помните об этом при настройке триггерных событий.

Триггеры и глобальные переходы

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

Глобальный переход позволяет любому статусу в рабочем процессе перейти к определенному статусу. Это представлено в средстве просмотра рабочего процесса / редактором черным цветом  категории статуса (поле которое связывает этап выполнения задачи и статус ), указывающие на статус, на который нацелен глобальный переход. Дополнительные сведения о глобальных переходах см. в разделе «Расширенная настройка рабочего процесса».

Настройка триггеров для глобальных переходов часто может привести к неожиданному переходу на целевой статус глобального перехода. Например, подумайте над тем, настроен ли триггер «Создана фиксация кода» (Commit created) для глобального перехода к статусу «В разработке» (In Progress) . Код фиксации может происходить на многих этапах во время жизненного цикла задачи (например, для написания исходного кода, изменения кода после проверки и т. д.). Это может привести к тому, что проблема будет неправильно переходить к «В разработке» (In Progress) из ряда статусов, таких как «В обзоре» (In Review) или «Готово» (Done).

Совет. Если вы используете глобальные переходы в своем рабочем процессе, у вас, вероятно, будет несколько переходов в статус. Это означает, что у пользователей будет несколько вариантов рабочего процесса по задаче (например, как «Начало прогресса» (Start progress), так и «В разработке» (In Progress)). Чтобы скрыть опции, добавьте условие «Скрыть переход от пользователя» (Hide transition from user)к соответствующим переходам.

Ссылка на задачу JIRA в  фиксации кода, ветви, перемещения запроса(request) или просмотра

В приведенной ниже таблице описывается, как ссылаться на задачу JIRA в  фиксации кода, ветви, перемещении запроса(request) или просмотре, чтобы эти события вызывали переходы для задачи (при условии, что вы настроили триггеры на переходы).

Событие

Инструкции

Создание фиксации кода

Включите ключ задачи в сообщение фиксации кода.

Например, сообщение фиксации, подобное этому «Первоначальная фиксация TIS-1», автоматически переместит задачу TIS-1 с «Сделать» на «В разработке».

Создание ветви

Включает ключ задачи в имя ветки при создании ветки.

Например, если вы назовете свою ветку «TIS-2-feature», она автоматически переместит задачу TIS-2 с «Сделать» на «В прогрессе».

Создание / повторное открытие / отклонение на слияние перемещения задачи

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

Например, если вы создаете перемещение задачи, которая имеет название «TIS-3» в заголовке, он автоматически переводит проблему «TIS-3» с «В процессе» на «В обзоре». Если вы повторно открываете, отклоняете или объединяете перемещение запроса(request), он также будет соответствующим образом переводить задачу «TIS-3».

Запуск / Отклонение / Отказ / Закрытие обзора

Включите ключ задачи в заголовок обзора, когда вы создадите обзор.

Например, если вы назовете свой обзор «TIS-4 New story» и начнете обзор, он автоматически переместит проблему TIS-4 с «В процессе» на «В обзоре». Если вы отклоняете, оставляете или закрываете обзор, он также будет соответствующим образом переводить задачу «TIS-4».

 

Пользовательское сопоставление от инструментов разработки до JIRA

Следующий процесс описывает, как пользователь инструмента разработки сопоставляется с пользователем JIRA для триггеров рабочего процесса. Он применяется ко всем событиям, однако каждый инструмент разработки использует другой адрес электронной почты и имя пользователя для сопоставления (см. Пункт маркера после описания процесса ниже).

  • Процесс: пользователь, инициирующий событие в инструменте разработки, сопоставляется с пользователем JIRA, сопоставляя адрес электронной почты, а затем имя пользователя, т. е.
    • Один пользователь JIRA с соответствующим адресом электронной почты — Перейдите к задаче как пользователь JIRA.
    • Нет пользователей JIRA с соответствующим адресом электронной почты — Перейдите к задаче как анонимный пользователь.
    • Несколько пользователей с соответствующим адресом электронной почты в JIRA — Попробуйте найти подходящее имя пользователя в этой группе пользователей. Если есть пользователь JIRA с совпадающим именем пользователя, перейдите к задаче как пользователь JIRA. Если нет совпадающего имени пользователя, перейдите к задаче как анонимный пользователь.
  • Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей:
    • Сервер Bitbucket

Собитие (я)

Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей

Все события перемещения запроса(request)

Адрес электронной почты сервера Bitbucket и  пользовательское имя пользователя, который выполнил перемещение запроса(request).

Созданная фиксация кода

Адрес электронной почты, связанный с фиксацией кода и именем пользователя Bitbucket Server, с которым  сопоставляется адрес электронной почты. Если адрес электронной почты не сопоставляется с именем пользователя, будут использоваться имена авторов из фиксации кода.

Созданная ветвь

Адрес электронной почты сервера Bitbucket и пользовательское имя аутентифицированного пользователя, который переместил ветвь на сервер Bitbucket.

 

  • FishEye / Crucible

Собитие (я)

Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей

Созданная фиксация

Адрес электронной почты, связанный с фиксацией кода и именем пользователя FishEye, на который указывает адрес электронной почты. Если адрес электронной почты не соотвествует  имени пользователя, будет использоваться «имя» автора из фиксации кода.

Созданная ветвь

Это событие не сопоставляется с пользователем JIRA. Это означает, что задача будет изменена как анонимный пользователь.

Все события обзора

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

 

  • Bitbucket

Событие (я)

Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей

Все события перемещения задачи

Адрес электронной почты Bitbucket и имя пользовательское имя, который выполнил перемещение задачи. Обратите внимание, что пользователь Bitbucket должен выполнить хотя бы одну фиксацию (с указанным адресом электронной почты для своего профиля), иначе задача на перенос не может быть сопоставлена пользователю JIRA. Это означает, что задача будет изменена на анонимного пользователя.

Созданная фиксация

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

Созданная ветвь

Это событие не сопоставляется с пользователем JIRA. Это означает, что задача будет изменена на анонимного пользователя.

  • GitHub / GitHub Enterprise

Событие(я)

Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей

Создана задача на перемещение  / задача на перемещение

Адрес электронной почты GitHub и  пользовательское имя пользователя, который выполнил перемещение задачи. Обратите внимание, что пользователю GitHub необходимо сделать хотя бы одну фиксацию (с указанным адресом электронной почты для своего профиля), иначе перемещение задачи не может быть сопоставлено с  пользователем JIRA. Это означает, что задача будет изменена на анонимного пользователя.

Созданная фиксация

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

Созданная ветвь

Это событие не отображается на пользователя JIRA. Это означает, что задача будет изменена на анонимного пользователя.

 

Обработка событий и ограничения событий

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

  • Обработка событий — события обрабатываются по-разному в зависимости от того, подключается ли инструмент разработки к JIRA через разъем DVCS или ссылку на приложение. Это может повлиять на то, что события задерживаются или теряются, когда JIRA недоступна:

Bitbucket и GitHub

События от Bitbucket и GitHub обрабатываются через коннектор DVCS в JIRA. Разъем DVCS обрабатывает события от Bitbucket и GitHub через два механизма синхронизации: синхронизации с помощью веб-сервисов и запланированной синхронизации.

  • Синхронизация с использованием Webhook: разъем DVCS использует веб-сервисы в Bitbucket и GitHub для отправки данных в JIRA при возникновении события. Это стандартный механизм обработки событий, что означает, что задачи должны автоматически переходить почти сразу после события Bitbucket / GitHub.
  • Синхронизация по расписанию: если JIRA нельзя связать, когда происходит событие Bitbucket / GitHub, событие сохраняется в коннекторе DVCS и отправляется при следующей запланированной синхронизации (каждые 60 минут, по умолчанию). Это резервный механизм в случае сбоя синхронизации с использованием веб-сервисов.

Тайник (Stash) и FishEye/Crucible

События с сервера Bitbucket и FishEye / Crucible обрабатываются по ссылке приложения. Тем не менее, Bitbucket Server и FishEye / Crucible отвечают за то, что отправляются события, и они отправляют их один раз в то время, когда происходит событие. Это означает, что если JIRA недоступна при отправке событий, события будут потеряны.

  • Ограничения на события — ограничения на события накладываются на все инструменты разработки, поэтому JIRA не перегружается слишком большим количеством событий. Любые события, отправленные после превышения предела события, теряются. Пределы событий для каждого инструмента разработки перечислены ниже:

Bitbucket и GitHub

  • Синхронизация с использованием Webhook: 10 ветвей; 100 коммитов
  • Плановая синхронизация: 600 ветвей (интервал синхронизации в минутах x 10); 6000 фиксаций (интервал синхронизации в минутах x 100)

Ограничения для запланированных синхронизаций могут быть менее 600 ветвей и 6000 фиксаций, если интервал синхронизации сокращен, но не больше.

Stash

10 филиалов; 100 фиксаций за синхронизацию

Дополнительным ограничением, которое применяется в дополнение к 10 ветвям и 100  ограничениям фиксаций, является ограничение на 100 000 событий изменений задач. Например, если 100 баллов за каждую ссылку превышают 1000 ключей задачи, предел изменения задач будет превышен.

FishEye / Crucible

6000 событий на синхронизацию

Как триггеры относятся к другим операциям / ограничениям рабочего процесса

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

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

Исправление проблем

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

  1. Используйте диагностику триггера
  2. Проверьте общие проблемы
  3. Получить помощь

Используйте диагностику триггера

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

  1. Перейдите к консоли администрирования JIRA> «Задачи» (Issues)> «Рабочие процессы» (Workflows)> Найдите свой рабочий процесс и нажмите «Обзор» (View (Operations) (столбец операций).

        2. В текстовом режиме (Text) (не в режиме диаграммы (Diagram)) щелкните требуемый переход.

На экране перехода (вкладка «Триггеры» (Triggers) будет отображаться), нажмите «Просмотреть детали» (View details) для нужного триггера, чтобы отобразить информацию диагностики.

  • В разделе «Источники триггеров» (Trigger sources) перечислены проблемы, связанные с интеграцией между JIRA и вашими инструментами разработки. Например, настроен ли у вас правильный тип аутентификации.
  • В разделе «Неудачи перехода» (Transition failures) перечислены задачи, которые не удалось автоматически перейти, несмотря на срабатывание триггера. Например, анонимный пользователь был сопоставлен с переходом, но переход имеет функцию post, для которой требуется не анонимный пользователь.

Проверьте общие проблемы

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

Я не могу добавить триггер перехода:

Возможные причины...

Причина

 Решение

JIRA или ваши инструменты разработки не являются правильной версией

Установите / обновите до нужной версии. Для включения триггеров рабочего процесса у вас должен быть JIRA 6.3.3+ и один из следующих средств разработки: Bitbucket Server (Stash 3.2.0) +, FishEye / Crucible 3.5.2+, Bitbucket, GitHub

Ваши инструменты разработки не подключены к JIRA правильно

Проверьте конфигурацию вашего соединения:

JIRA + сервер Bitbucket / FishEye / Crucible: вам нужно настроить двустороннюю связь приложения с помощью Oauth с 2LO и 3LO.

JIRA + Bitbucket / GitHub: вам необходимо правильно настроить коннектор DVCS.

Подробнее см.

Триггер, который вы пытаетесь добавить, уже добавлен к переходу

Ничего не делайте.

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

 

Задача не делает переход

Причина

Решение

В вашем проекте не используется рабочий процесс, настроенный с помощью триггеров

Перейдите в сводку вашего проекта> Администрирование> Рабочие процессы и убедитесь, что в вашем проекте используется рабочий процесс, который вы настроили с помощью триггеров.

Вы не сохранили изменения рабочего процесса, в которые были добавлены триггеры

Перейдите к рабочему процессу, к которому добавлены триггеры. Убедитесь, что он был опубликован, просмотрев переходы рабочего процесса и подтвердив, что ваши триггеры присутствуют.

JIRA не может быть достигнут вашим DVCS

Подождите час. Если по истечении часа он не может быть достигнут, убедитесь, что соединение с вашим DVCS настроено правильно, см.

 

Если триггеры не настроены или JIRA недоступен из Bitbucket / GitHub, тогда задержка может составлять до одного часа, так как по-прежнему происходит часовая синхронизация фиксаций / ответвлений / запросов на передачу, происходящих независимо от конфигурации триггеров. Для получения дополнительной информации см. Раздел «Обработка событий и ограничения событий» выше.

Репозиторий DVCS не связан с синхронизированной учетной записью DVCS

Перейдите в консоль администрирования JIRA> надстройки> учетные записи DVCS и включите ваш репозиторий.

Если вы не настроили Bitbucket или GitHub для автоматического связывания новых репозиториев, у вас могут быть репозитории, которые не включены (т. е. связаны с вашей учетной записью DVCS). Это означает, что события из несвязанного репозитория не будут отправляться в JIRA, поэтому задача не будет автоматически переходить, даже если вы настроили триггер.

Ваши фиксации (коммиты) слишком стары

Только фиксация менее 21 дня приведет к переходу. Это делается для предотвращения массовых пересылок файлов от массовых переходов.

Если вы хотите обойти это, вы можете изменить ограничение на 21 день, отредактировав файл jira-config.properties (в вашем домашнем каталоге JIRA) и добавив следующее свойство:

jira.devstatus.commitcreated.age.timeout = P2D

где P2D - пример длительности ISO-8601, представляющей 2 дня.

Операция не разрешена для анонимных пользователей

Операция не разрешена для анонимных пользователей. Убедитесь, что каждый пользователь в ваших инструментах разработки сопоставляется с пользователем JIRA.

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

•  Событие CreateIssue (это, вероятно, связано с переходом «Создать» или «Создать задачу» в вашем рабочем процессе)

•  Пост-функции , которые предполагают что пользователь, выполняет переход

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

 

 

Максимальное количество автоматических переходов, разрешенных для задач, превышено

Убедитесь, что переходы вашего рабочего процесса не заканчиваются бесконечным циклом.

По умолчанию разрешено только 50 автоматических переходов. Это делается для предотвращения застревания задач в бесконечных циклах. Если на ваш рабочий процесс требуется более 50 автоматических переходов для каждой задачи, вы можете переопределить это ограничение, отредактировав файл jira-config.properties (в домашнем каталоге JIRA) и добавив / обновив следующее свойство:

jira.automatic.transitioning.issue.limit

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

Измените настройки репозитория / проекта, чтобы можно было отправлять события.

 

Возможно, вы настроили хранилища Bitbucket Server (Stash 3.3 - 3.5) или FishEye (3.5+) для подавления событий, отправленных JIRA для триггеров рабочего процесса, если были отправлены повторяющиеся события. Дублированные события репозитория могут быть отправлены в JIRA, если у вас есть тот же репозиторий, индексированный несколькими инструментами разработки. Примечание. JIRA автоматически удаляет повторяющиеся события фиксации (JIRA 6.3.3+) и события создания ветки (JIRA 6.3.11+) при обработке триггеров рабочих процессов.

 

Вы не должны подавлять события репозитория с сервера Bitbucket или FishEye, если только повторяющиеся события не вызывают неправильного перехода к ошибкам. Для получения инструкций см. Триггеры рабочего процесса JIRA (документация FishEye).

 

Задача переходит, но не так, как ожидалось:

Причина

Решение

Вы настроили триггер для глобального перехода

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

Мы не рекомендуем настраивать триггеры для глобальных переходов, если вы не уверены, что понимаете, как триггер повлияет на поведение задачи. Дополнительную информацию см. в разделе «Триггеры и глобальные переходы».

Условия рабочего процесса, валидаторы и разрешения намеренно игнорируются для автоматических переходов задач

Ничего не делайте.

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

Ваш рабочий процесс доступен для нескольких проектов

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

 

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

Дублирующие события автоматического перехода задачи отправляются несколькими инструментами разработки

Измените параметры репозитория / проекта в одном (или нескольких) инструментах разработки, чтобы предотвратить отправку событий.

 

Дублированные события репозитория могут быть отправлены в JIRA, если у вас есть тот же репозиторий, индексированный несколькими инструментами разработки. JIRA автоматически удаляет повторяющиеся события фиксации (JIRA 6.3.3 и более поздние) и события создания ветвей (JIRA 6.3.11 и более поздние).

 

Если вы не используете последнюю версию JIRA и не имеете повторяющихся событий репозитория, вызывающих неправильные переходы задач, вы можете настроить репозитории Bitbucket Server (Stash 3.3 - 3.5) и FishEye (3.5+) для подавления событий, отправленных JIRA для триггеров рабочих процессов. Для получения инструкций см. Интеграцию JIRA (документация сервера Bitbucket) или триггеры рабочего процесса JIRA (документация FishEye).

 

Информация, записанная для перехода, неверна:

Причина

Решение

Пользователи в ваших инструментах разработки не отображают пользователей в JIRA

Убедитесь, что каждый пользователь в ваших инструментах разработки сопоставляется с пользователем JIRA.Если пользователи неправильно настроены, то пользователь для перехода задачи будет анонимным. Для получения дополнительной информации см. выше «Раздел о сопоставлении пользователей» .

Известная проблема. Правильный пользователь отображается только на вкладках «История» и «Активность» для проблем в JIRA и в уведомлениях. В других уведомлениях, например. отображается вкладка «Переходы» для задач, уведомления HipChat и т. д., анонимный пользователь.

Ничего не делайте

Это известная проблема, которая будет исправлена в будущей версии.

 

Получение помощи

Если вы все еще не можете решить свою проблему, есть ряд других справочных ресурсов, включая наши форумы продуктов, ответы Atlassian Answers и нашу службу поддержки. Подробнее см. в разделе «Получение справки».

По материалам Atlassian JIRA Administrator's Guide: Configuring workflow triggers