Jira — тьюринг-полная

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

Составление вычислительной модели

Для машины Минского требуются всего два неограниченных счётчика и конечное множество именованных команд:

• INC r; goto S

• DEC r; if r == 0 goto S else goto S'

Если говорить русским языком:

• выполнить инкремент регистра R, затем перейти в некое состояние S

• выполнить декремент регистра R, если R == 0, перейти в нулевое состояние S, иначе перейти в ненулевое состояние S’

Программа Минского, складывающая регистр A с регистром B и сохраняющая значение в B, выглядит так:

1. DEC A; if A == 0 goto 3 else goto 22. INC B; goto 13. HALT

Минский доказал, что эта модель Тьюринг-полная (1967 год). Следовательно, продемонстрировав её на языке автоматизации Jira, мы получим нужное нам доказательство. Вот, как модель связывается с Jira:

В статусе Epic кодируется текущая команда. Правила автоматизации проверяют количество связанных задач и выбирают следующий статус. INC и DEC реализованы как создание и удаление задачи соответствующего типа связанной задачи. Условное ветвление реализовано в виде условного правила JQL.

Реализация сложения

Ниже представлена минимальная работающая реализация на основе одной Epic, пяти связанных задач и одного правила автоматизации на каждое состояние команды (Space Settings > Automation).

1. Создание Workflow

Создаём Jira Workflow со статусами начальных состояний BACKLOG, затем TODO, DEV и PROD. Любое состояние может выполнять переход в любое другое.

Создаём Epic в статусе BACKLOG.

2. Создание правила для TODO

DEC A; if A=0 halt, else goto DEV.

• Триггер: статус Epic изменён на TODO.

• Если есть хотя бы один связанный Bug: удаление одного Bug, переход Epic в состояние DEV.

• Иначе: переход Epic в PROD (останов).

3. Создание правила для DEV

INC B; goto TODO.

• Триггер: статус Epic меняется на DEV.

• Создание новой задачи, привязка её к Epic.

• Переход Epic в состояние TODO.

У обоих правил выставлен флаг «Разрешить этому правилу вызывать другие правила».

На скриншоте ниже показаны два правила, связанные с workflow Epic.

4. Инициализация регистров

Привязываем 2 Bug (A=2) и 3 Task (B=3) к Epic.

5. Запуск машины.

Выполняем переход Epic в состояние TODO для запуска каскада. Пять переходов:

(2,3) TODO → (1,3) DEV  → (1,4) TODO → (0,4) DEV  → (0,5) TODO → (0,5) PROD

Записано на реальном инстансе *.atlassian.net.

Epic оказывается в состоянии PROD с 0 связанных Bug и 5 связанных Task. Так мы выполнили сложение 2 + 3 = 5.

Вычисление чисел Фибоначчи в трёх состояниях

Приведённого выше доказательства достаточно для демонстрации полноты по Тьюрингу. Наряду с этим язык автоматизации Jira может упрощать операции Минского. Convert Issue Type мгновенно меняет тип задачи: Bug → Story, Story → Task и так далее.

CONVERT можно выразить как DEC + INC. Она не повышает вычислительную мощь Jira, но существенно уменьшает таблицу диспетчеризации для цикла копирования, что позволяет реализовывать нетривиальные программы.

Вычисление чисел в Фибоначчи в виде (A, B) → (B, A+B) сводится к трём состояниям с тремя регистрами (A=Bug, B=Task, C=Story); тремя состояниями команд будут TODO, QA (нужно добавить его в workflow) и DEV:

TODO:    if any linked Task exists:        CONVERT Task → Story        INC Bug        transition to TODO    else:        transition to QAQA:    if any linked Bug exists:        CONVERT Bug → Task        transition to QA    else:        transition to DEVDEV:    if any linked Story exists:        CONVERT Story → Bug        transition to DEV    else:        transition to TODO

Начальное состояние имеет вид A=1, B=1, C=0. Последовательность 1, 1, 2, 3, 5, 8, 13, … записывается в B (счётчик Task).

В отличие от машины сложения, у машины Фибоначчи нет состояния останова. Она работает, пока не упрётся в максимальную глубину цепочек прав, равную 10 срабатываниям; после этого оператор заново запускает Epic для продолжения. Для перезапуска каскада достаточно одного изменения статуса.

Доказательство по-прежнему в силе, живой оператор просто передаёт машине следующий такт. В Jira Data Center есть аналогичное свойство automation.rule.execution.timeout и связанные с ним конфигурируемые свойства.

Заключение

Язык автоматизации Jira при условии неограниченного создания задач и исполнения правил способен закодировать машину с двумя счётчиками . Все физические компьютеры конечны, поэтому конечный лимит Jira Cloud не опровергает наши построения. В рамках этого стандартного допущения Jira полна по Тьюрингу.

Поэтому если сложные автоматизации Jira кажутся вам похожими на программы, то это потому, что именно так всё и есть.