Lookup в Jira Cloud Automation: почему найдены не все задачи

Задача: отличить неполную выборку от ошибки правила

В обычном поиске Jira видны нужные задачи, но отчёт автоматизации показывает меньше строк или неожиданно возвращает ноль. Прежде чем менять дальнейшие действия, нужно проверить сам поиск: одинаков ли JQL, доступны ли задачи актору и не достигнуто ли ограничение результата. Успешный статус выполнения ещё не означает, что отчёт охватил весь бэклог.

Разберём учебный пилот Jira Cloud. Действие Lookup issues в новом интерфейсе может называться Lookup work items, а правило — flow. В документации для этого действия указан предел: используются первые 100 результатов JQL. Это ограничение конкретного компонента, а не утверждение о максимальном числе задач в проекте. Перед масштабированием сверяйте актуальные service limits.

Далее правило только читает данные и пишет диагностические строки в audit log. Оно не отправляет письма, не добавляет комментарии и не изменяет найденные задачи. Cloud обновляется непрерывно; для Data Center проверяйте установленную версию Automation, доступность компонента и его ограничения отдельно. Пилот в реальной Jira при подготовке материала не выполнялся.

Согласуйте область и акторскую учётную запись

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

Запишите выбранного актора, область правила, исходный JQL и ожидаемые ключи контрольных задач. Для каждой задачи важен доступ к проекту и её видимость с учётом безопасности задач. Если актор не является обычной интерактивной записью, не пытайтесь войти под ним: необходимые разрешения проверяет администратор. Не выдавайте глобального администратора только ради совпадения счётчиков.

До запуска проверьте доступный объём автоматизаций по вашему плану. Чтение без изменения задач не означает отсутствие ограничений сервиса. Для диагностики достаточно нескольких ручных запусков; частое расписание и увеличение частоты здесь не нужны. Не меняйте рабочее правило, пока маленький отдельный пилот не объяснил расхождение.

Подготовьте три совпадения и одну исключённую задачу

Выберите четыре нейтральные тестовые задачи. Трем добавьте метку pilot-lookup-check, четвёртую оставьте без неё. Ключи в примере ниже условные: используйте фактические ключи своей среды. До изменения сохраните исходные метки и убедитесь, что учебное значение не используется действующими правилами или отчётами.

Проверьте запрос в расширенном поиске Jira и запишите результат. Важно сравнивать полный одинаковый JQL, а не похожий сохранённый фильтр с дополнительными условиями. Не добавляйте ограничения по исполнителю, датам или статусу без необходимости. Для первого прохода ожидаются ровно три известных ключа; четвёртый должен отсутствовать.

Учебные данные:
PILOT-1, PILOT-2, PILOT-3: label pilot-lookup-check
PILOT-4: без этой метки

JQL:
project = PILOT AND labels = pilot-lookup-check ORDER BY key ASC

Соберите правило из ручного запуска, поиска и журнала

В Automation учебного проекта создайте отдельное диагностическое правило. Выберите Manual trigger from work item и ограничьте разрешённую группу запуска по согласованным условиям. Затем добавьте Lookup work items с проверенным JQL. После него добавьте Log action со строкой ниже. Все компоненты расположите последовательно; ветки и дополнительные поиски в этом пилоте не нужны.

Включите правило и запустите его из Actions на согласованной учебной задаче. Откройте именно запись этого запуска в audit log и проверьте результат Lookup и диагностическую строку. Для подготовленного набора ожидаются count=3 и три контрольных ключа. Порядок ключей определяется JQL; для проверки полноты сравнивайте сам набор, а не только длину строки.

В журнал выводятся только количество и нейтральные ключи. Не используйте полный lookupIssues как отладочный дамп рабочих объектов: он может раскрыть лишние данные. Если правило позже применяется к закрытым задачам, заранее согласуйте, кому доступен его журнал.

lookup-pilot | count={{lookupIssues.size}} | keys={{lookupIssues.key.join(", ")}}

Сверьте JQL, права и момент выполнения

Если число отличается от трёх, сначала скопируйте JQL из компонента и повторно сравните его с контрольным запросом. Проверьте имя проекта, точное значение метки и фактическое сохранение изменений. Затем сопоставьте каждый пропавший ключ с доступом актора. Результат поиска администратора не является эталоном видимости для любой учётной записи.

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

Если в журнале нет ожидаемого запуска, разберите ручной триггер и разрешение запуска. Если есть ошибка компонента, начните с её сообщения. Не добавляйте Delay как универсальное исправление: пауза не делает неправильный JQL правильным и не выдаёт недостающие права.

Проверьте пустой результат и границу ста задач

Для отрицательного теста временно замените метку в запросе на pilot-lookup-no-match, предварительно убедившись, что её нет в учебном проекте. После ручного запуска ожидается count=0 и отсутствие ключей в диагностической строке. Сверьте audit log, затем верните исходный JQL и подтвердите count=3. Это отделяет реальную пустую выборку от сообщения, прочитанного в старом запуске.

Для уже существующего согласованного набора, в котором одинаковый JQL под тем же доступом находит больше 100 задач, Lookup вернёт не более 100. Не создавайте сотни рабочих задач только для демонстрации лимита. Если число достигло 100, полноту нельзя подтвердить одним lookupIssues.size: реальных совпадений может быть ровно сто или значительно больше.

Увеличение подписки само по себе не следует считать решением ограничения этого компонента. Для полного отчёта определите непересекающиеся части выборки и отдельно проверьте объединённый результат либо используйте подходящую выгрузку через REST с обработкой страниц. Разделение по случайному времени запуска без сохранённой границы может дать пропуски и дубли.

• Малый набор: три ожидаемых ключа, исключённая задача отсутствует.
• Пустой набор: ноль результатов после смены только учебной метки.
• Количество 100: полнота отчёта требует отдельной проверки.
• Количество меньше 100: права и корректность JQL всё равно нужно подтвердить.

Защитите последующий отчёт от ложного полного итога

Если диагностику включают в отчётное правило, перед публикацией итога добавьте явную проверку границы: в условии сравнения smart values (Advanced compare в прежнем интерфейсе) сравните {{lookupIssues.size}} с 99 оператором Greater than. В ветке достижения границы фиксируйте сообщение о неподтверждённой полноте и не выдавайте такой результат за общий итог. В диагностическом пилоте достаточно Log action; внешние уведомления пока не добавляйте.

Этот контроль не доказывает полноту любой меньшей выборки. Неверный запрос или ограниченный доступ могут дать и ноль, и несколько строк. Приёмка должна учитывать ожидаемые ключи и роль исполнителя. Также не приравнивайте поиск к изменению всех найденных задач: дальнейшие действия и их права требуют собственного проекта и проверки.

Если после Lookup появился ещё один поиск или ветка, заново проверьте, какие smart values используются в каждой точке. Не считайте диагностическую строку из раннего компонента описанием всех последующих шагов. Сохраняйте порядок действий и понятные подписи журнала, чтобы разбор не зависел от памяти автора правила.

Отключите пилот и сохраните результат проверки

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

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

Передайте владельцу JQL, актора, область, ожидаемые ключи, результаты пустой выборки и вывод о границе 100. В материале проверена официальная документация; реальных запусков Jira не было. Диагностика вашей среды завершена только после наблюдения этих результатов, а перенос в рабочий отчёт требует отдельной проверки полноты и дальнейших действий.