Автоматизації

Автоматизації виконують інструкцію за розкладом і доставляють результат як звичайний чат. Щоденне зведення новин, тижневий огляд, місячний звіт — кожне виконання працює на сервері без інтерфейсу, з’являється у списку чатів і продовжується як будь-який діалог.

Структура

Автоматизація має ім’я, довільні інструкції, до п’яти тригерів, необов’язкову модель (порожньо означає Auto: модель чату користувача під час виконання), мету й налаштування сповіщень. Chat session типово ставить інструкцію в чергу розмови, а Work task запускає ізольовану пісочницю Work з інструкцією як першим повідомленням, за потреби за вибраною іменованою політикою. За ввімкнених сповіщень помилка також потрапляє до центру сповіщень, навіть якщо Automations закрито. Окремо від цього, перемикач Результати автоматизацій у Settings → Notifications → Сповіщення електронною поштою надсилає вам поштою результат кожного запуску, щойно адміністратор налаштує сервер вихідної пошти (див. Сповіщення). Імена й інструкції зашифровано у стані спокою. Автоматизація належить творцю.

Тригери використовують модель календаря — once, hourly, daily, weekly, monthly, yearly — і автоматизація може мати до п’яти тригерів. Наступне виконання — найраніша майбутня подія, обчислена в локальній зоні сервера.

Тригери за подією

Сьомий вид, event, узагалі не має годинника: він спрацьовує, коли надходить одне з ваших сповіщень.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event — це будь-який тип сповіщення, крім automation-failed: процедура не повинна мати змогу перезапустити себе через власне повідомлення про невдачу. Необов’язковий match — це пошук підрядка без урахування регістру в заголовку сповіщення; без нього процедуру запускає кожне сповіщення цього типу.

Тригер за подією ніколи не задає час наступного виконання. Автоматизація, у якої всі тригери — події, тому не показує наступного запуску: список і діалог редагування натомість кажуть Спрацьовує, коли…. Поєднувати тригер за подією з розкладом можна без проблем — заплановані тригери й далі керують годинником.

Дві межі обмежують радіус дії. Процедура спрацьовує від подій не частіше одного разу на хвилину, хоч би як активним був потік, і власне сповіщення про невдачу запуску ніколи не запускає повторно процедуру, яка його створила.

Запуск отримує те, що його спричинило, дописане до своїх інструкцій:

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Виконання

Планувальник з координаційною орендою спрацьовує щохвилини, тому розклади просуває одна репліка. Коли настає термін, він записує виконання, ставить постійне завдання automation.run.v1 і оновлює next_run_at через compare-and-set, щоб подія спрацювала щонайбільше раз. Завдання створює чат із назвою автоматизації й передає інструкцію через той самий постійний ланцюжок генерування, з маршрутизацією, персоною та збереженням.

Якщо сервер був вимкнений, наступний крок виконує останню пропущену подію раз і пропускає старіші. Призупинення очищує розклад; відновлення чи редагування обчислює його від поточного часу. Видалення каскадно видаляє історію.

Стан береться з постійного журналу: успіх після генерування, помилка після черги невдалих завдань і stalled, якщо виконання не почалося за 30 хвилин.

Мета Work використовує життєвий цикл Work замість чат-завдання: запис пов’язується зі створеним завданням, Runs веде до нього, успіх настає після завершення агента або запиту введення, помилка — за збою чи скасування. Лист із результатом для запуску з метою Work містить підсумок, який зберіг сам запуск Work — те, на чому зупинився агент, той самий текст, що показує історія запусків завдання, — і повертається до однорядкового статусу завдання, якщо запуск старіший за появу збережених підсумків. Доступ перевіряється під час спрацювання, тому його відкликання вимикає автоматизації Work; виконання чесно завершується як work-access-denied. Політика перевіряється під час збереження, а мережа й ліміти застосовуються до всіх завдань. У Work працюють лише прямі постачальники, модель має підтримувати інструменти.

Процедури агентів

Автоматизація Work може пов’язатися з наявним завданням через workTaskId — це основа Routines у панелі агента. Вона не створює нового завдання: кожна подія запускається в його просторі й діалозі з моделлю, постачальником і політикою завдання, тому поля автоматизації не діють, а передана політика видаляється. Зв’язок перевіряється під час збереження. Видалене завдання дає work-task-missing, зайняте або з активним переглядом — work-task-busy, а не чергу.

Вебхук-тригери

Крім розкладу, автоматизацію може запустити зовнішня система — конвеєр CI, служба cron, домашня автоматизація. У діалозі редагування автоматизації Вебхук-тригер → Увімкнути створює секрет для цієї автоматизації; зберігається лише його SHA-256, тож відкритий текст показують рівно один раз. Зміна секрету миттєво скасовує попередній, а вимкнення вебхука знову закриває кінцеву точку.

Зовнішня система запускає автоматизацію так:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..."

(Як альтернативу можна надіслати заголовок X-Libre-Webhook-Secret: lwh_....) Відповідь — 202 з ідентифікатором поставленого в чергу виконання: це той самий шлях ручного запуску, що й Запустити зараз, тому виконання так само завершуються, надсилають сповіщення й потрапляють до історії. Порівняння секрету відбувається за сталий час, відсутня автоматизація й хибний секрет відповідають однаково (жодного оракула ідентифікаторів), а призупинена автоматизація відповідає 409: на відміну від власника з «Запустити зараз», зовнішній виклик не може пробитися крізь паузу.

Об’єкт JSON у тілі запиту потрапляє в запуск як його корисне навантаження тригера, тож процедура бачить, на що вона реагує:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..." \
  -H "Content-Type: application/json" \
  -d '{"commit":"abc123","branch":"main"}'

Навантаження дописується до інструкцій, які виконує запуск, під заголовком Trigger payload (JSON): — однаково для чат-запусків, нових завдань Work і прив’язаних процедур. Переносяться лише об’єкти JSON (масиви й скаляри ігноруються), а навантаження, серіалізована форма якого перевищує 4000 символів, відкидається, а не обрізається, із попередженням у журналі сервера. Спрацювання без тіла запиту поводиться так само, як і раніше.

API

Усі кінцеві точки, крім запуску через вебхук, потребують автентифікації й працюють лише з автоматизаціями викликувача; запуск через вебхук натомість автентифікується секретом цієї автоматизації.

Метод	Шлях	Призначення
GET	/api/automations	Список
POST	/api/automations	Створення
GET	/api/automations/occurrences?from=&to=	Майбутні події
GET	/api/automations/runs	Історія з фільтрами
GET	/api/automations/runs/summary	Непереглянуті + періоди 30 днів
POST	/api/automations/runs/seen	Позначити завершені переглянутими
GET	/api/automations/:automationId	Прочитати одну
PUT	/api/automations/:automationId	Оновити
DELETE	/api/automations/:automationId	Видалити
POST	/api/automations/:automationId/pause	Призупинити
POST	/api/automations/:automationId/resume	Відновити
POST	/api/automations/:automationId/run	Запустити зараз (202 з ID)
POST	/api/automations/:automationId/webhook	Запуск за секретом (202)
POST	/api/automations/:automationId/webhook-secret	Створити або змінити секрет
DELETE	/api/automations/:automationId/webhook-secret	Вимкнути вебхук

Користувач може зберігати до 50 автоматизацій; ім’я обмежено 200 символами, інструкцію — 20 000.