2026 Малые команды и общий удалённый Mac: Jira Automation — маршрут меток на узлы, замки сборки и чеклист таймаутов

Jira Automation удобно шлёт HTTPS на ваш шлюз или на обёртку у self-hosted runner, но на общем Mac это быстро превращается в хаос: две задачи с меткой «срочно» стартуют архив сразу, третья — UI-тесты в том же пользователе macOS, пока первая ещё держит codesign. Инженеры видят зелёный переход в Jira и красный лог на хосте — потому что коллаборация по SSH и CI делят один login keychain и один слот Simulator без явной политики.

Три сигнала, что пора вводить матрицу: (1) задержка не в компиляции, а в ожидании замка или очереди; (2) «плавающие» падения после ручного перезапуска Automation; (3) рост времени от webhook до комментария в задаче из-за ретраев 429/5xx без дисциплины backoff. Для сопоставления с GitHub-стороной см. merge queue, метки runner и таймауты и маршрутизацию runner и очередей.

SSH, коллаборация и CI на одном хосте редко уживаются без разделения ролей. Короткая матрица выбора:

• Прямой SSH разработчика — отдельный пользователь или отдельный узел; не смешивать с учёткой ci, иначе ломаются профили Xcode и кэши. См. Codespaces (SSH) vs прямой узел.
• Только Jira → скрипт по SSH — минимальная связка, но максимальный риск гонок; обязательны неинтерактивный ключ, ForceCommand или обёртка только на enqueue.
• Jira → шлюз → очередь → runner — рекомендуемый контур для общего Mac: тонкий webhook, тяжёлая работа в известном worker, единая точка rate limit. Паттерны ретраев — в очереди и повторах задач.

Согласуйте имена меток Jira с метками runner или с полем «целевой узел» в теле webhook — одна таблица в runbook снимает споры между трекером и эксплуатацией.

Webhook Jira не должен выполнять произвольный shell от имени человека-владельца ноутбука. Заведите сервисного пользователя macOS для CI, отдельный automation keychain и каталоги артефактов с setgid или ACL по группе роли — иначе Jira станет косвенным remote shell. SSH-ключи ротируйте по ролям; матрица вилок Ansible и сертификатов — в SSH-ротации и вилках.

На шлюзе держите один секрет на Automation (заголовок или HMAC по сырому телу), лимиты запросов и логирование X-Automation-Request-Id — это снижает риск дублей и перегруза; см. лимиты шлюза и конкурентность сессий. Для живых сессий разработчиков и VNC оставьте отдельную политику — SSH/VNC и изоляция прав.

Правило Automation должно передавать не только issue.key, но и стабильный ключ идемпотентности: например связка issue.key + идентификатор перехода/комментария из smart values или отдельное числовое поле «ID запроса сборки», которое скрипт увеличивает один раз при постановке. Шлюз хранит последний принятый ключ в течение окна TTL (15–60 минут) и отвечает 200 с no-op или 409, чтобы Jira не устроила веер повторов.

В теле webhook фиксируйте: ключ задачи, набор меток для маршрута, ветку Git, SHA (если уже известен), initiator и transition id. Не полагайтесь на «последний комментарий» как единственный триггер — его легко задублировать. Мультиузловой контур Jira → OpenClaw разобран в практике Jira webhook на MeshMac.

После постановки в очередь обновляйте кастомное поле «Состояние сборки» через REST с тем же backoff, что и для других интеграций; общие принципы входящих webhook описаны для смежных систем в практике Asana webhook (подпись, сырое тело, дедуп).

Если несколько правил Jira завязаны на одну метку, явно разведите их по условию JQL или по проекту — иначе идемпотентность на шлюзе станет единственной защитой. Дополнительные вопросы по очередям без вендорского планировщика — FAQ по очереди и замкам.

Два перехода статуса подряд запустили две сборки на один SHA — какой отменять?

Отменяйте более старый idempotency key на шлюзе; в Jira оставьте ссылку на актуальный run. Не отменяйте job, который уже взял flock подписи — дождитесь критической секции и пометьте второй как «superseded».

Метка в Jira говорит «release», а runner занят PR — кто прав?

Политика вытеснения должна быть в таблице приоритетов: релиз выше PR, но не выше уже идущей нотаризации. Либо отдельный узел ci-release, либо отказ с понятным комментарием и повтором из очереди.

Зависший flock заблокировал все Jira-сборки — что проверить первым?

PID держателя, наличие zombie runner, таймаут ожидания lock. Снимайте блокировку только после подтверждения, что процесс мёртв; профилактика — короткий timeout вокруг шага и алерт. Подробнее в FAQ по flock.

Нужен ли отдельный merge queue, если триггер только из Jira?

Если код живёт в GitHub/GitLab, очередь на стороне Git всё равно влияет на консистентность ветки; Jira лишь оркестратор. См. связку в статье про merge queue и runner.

Кратко: Jira Automation на общем Mac работает устойчиво, когда метки однозначно мапятся на узлы, шлюз обеспечивает идемпотентность, а критические шаги сериализованы flock или очередью с документированными таймаутами. SSH для людей и CI для роботов разведены по учёткам и ключам; релизы не делят один слот с экспериментальными workflow.

Если очередь из Jira регулярно упирается в один узел, масштабирование честнее, чем бесконечное удлинение таймаутов: добавьте второй удалённый Mac под метку ci-release или расширьте командный пакет MeshMac — так метки остаются простыми, а инфраструктура послушной. Оформление и просмотр тарифов доступны с публичных страниц без входа в аккаунт (см. блок ниже).