Пользовательские скрипты

Scripts are the lightest-weight entry point into Behavior Extensibility – Python code that runs on the platform server and can be triggered, scheduled, or called from within larger automation flows.

В рамках Behavior Extensibility скрипты представляют собой серверные Python-скрипты, выполняемые в контексте платформы Altium 365. В отличие от скомпилированных расширений или полноценной автоматизации workflow, скрипты намеренно сделаны легковесными: один файл, определенный контракт ввода/вывода и узконаправленное назначение. Их можно запускать вручную, вызывать из hooks, встраивать в workflows как шаги или планировать для регулярного выполнения.

Скрипты используют ту же инфраструктуру расширяемости, что и checks, hooks и workflow blocks, — у них есть доступ к данным Workspace, они могут вызывать внешние системы, а результаты их работы могут передаваться в другие части конвейера автоматизации. Разница заключается в масштабе: скрипт делает одну задачу, делает ее чисто и позволяет быстро вносить изменения.

Для чего используются Scripts в этом контексте

• Targeted automation – скрипт, который выполняется один раз при запуске, – нормализация значений параметров компонентов во всей библиотеке, генерация пользовательского отчета на основе данных Workspace, отправка набора данных во внешнюю систему после релиза. Это целевые операции, которые не нужно встраивать в полный фреймворк checks или workflows.

• Data transformation – скрипты являются правильным инструментом, когда данные нужно преобразовать между системами – например, преобразовать структуры данных Altium в формат, ожидаемый внешним API, или преобразовать входящие данные перед их записью в Workspace. Чистую логику преобразования в скрипте проще тестировать и поддерживать, чем преобразование, скрытое внутри более крупного workflow.

• Policy enforcement, lightweight – для правил контроля, которые не должны выполняться в автоматических контрольных точках – например, правил, которые руководитель команды запускает перед проверкой очередного этапа, или проверок, вызываемых по требованию, а не при каждом commit, – скрипт подходит лучше, чем полноценный check, зарегистрированный на событие платформы. Издержки полной инфраструктуры checks не оправданы, когда запуск выполняется осознанно и вручную.

• Building blocks for larger automation – скрипты можно вызывать из hooks и workflow blocks, что делает их повторно используемыми единицами в составе более крупной автоматизации. Например, скрипт, который запрашивает внешний список одобренных поставщиков, можно вызывать из нескольких разных checks и hooks без дублирования логики. Скрипт отвечает за взаимодействие с внешней системой; check или hook отвечает за принятие решения согласно политике.

Scripts и другие примитивы Behavior Extensibility

Scripts не заменяют checks, hooks или workflow blocks – это дополняющий примитив с иной ролью:

Checks привязаны к событиям валидации платформы и автоматически выполняются в заданных контрольных точках. Scripts выполняются только при явном вызове.

Hooks реагируют на события жизненного цикла платформы и срабатывают автоматически. Scripts вызываются целенаправленно – пользователем, по расписанию или из другого примитива автоматизации.

Workflow blocks — это повторно используемые шаги внутри определений workflow. Scripts могут реализовывать логику, которую вызывает workflow block, но сам по себе script не является шагом workflow.

Начинайте со script, если требуется целевая операция, выполняемая по запросу или по расписанию. Переносите логику в check или hook, когда она должна запускаться автоматически по событиям платформы. Оборачивайте ее в workflow block, когда ее нужно включать в структурированные многошаговые процессы.

Поддержка и итерации

Scripts — это Python-файлы, они хранятся в системе контроля версий, как и любой другой код. Поскольку они интерпретируемые и не требуют этапа сборки, итерации происходят быстро: изменить скрипт, развернуть, протестировать. Это делает scripts правильной отправной точкой, когда точные требования еще не полностью определены или когда логика должна быстро эволюционировать в ответ на реальное использование.

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