Skip to content

Архитектура автоматизации GitHub → Linear

🧩 Архитектура: что с чем связано

Данная автоматизация реализует создание задач в Linear непосредственно из процессов GitHub. Это позволяет связывать задачи с кодом, пулл-реквестами и автоматизировать рутину. Схема работы: 1. Триггер: Событие в GitHub (например, пуш в определенную ветку или ручной запуск workflow) инициирует выполнение GitHub Actions. 2. Действие: GitHub Actions выполняет HTTP-запрос (GraphQL mutation) к API Linear. 3. Мутация: Запрос содержит мутацию issueCreate, которая и создает новую задачу. 4. Аутентификация: Для подтверждения прав на создание задачи используется Personal API Key Linear. Этот ключ передается в заголовке Authorization запроса. 5. Конфигурация: Параметры задачи, такие как teamId (команда) и projectId (проект), не "зашиты" в код workflow, а вынесены в GitHub Secrets. Это сделано для безопасности и гибкости: секреты можно менять без изменения самого скрипта, и они не видны в публичной части репозитория.

🏷️ Типы лейблов в Linear: почему используется только один

При разработке автоматизации важно было разобраться в двух типах лейблов, существующих в Linear, чтобы выбрать правильный для маркировки задач.

1. Issue labels (лейблы задач) ✅ Используем

Это лейблы, которые назначаются конкретным задачам (issues). Они идеально подходят для классификации, приоритизации и автоматизации рабочих процессов. Именно этот тип лейблов используется в нашей автоматизации, так как они поддерживаются в мутации IssueCreateInput (поле labelIds).

2. Project labels (лейблы проектов) ❌ Не используем

Это лейблы, которые назначаются на проект целиком, а не на отдельные задачи внутри него. Они служат для классификации самих проектов (например, "Внутренний", "Клиентский", "Маркетинг"). Критическое различие: Project labels не поддерживаются в IssueCreateInput.labelIds. Их нельзя использовать для автоматической маркировки создаваемых задач. Поэтому в текущей автоматизации публикации постов они сознательно исключены, несмотря на то, что доступны через API.

💡 Обоснование архитектурных решений

  • Использование GitHub Secrets: Это стандарт безопасности. Ключи API и идентификаторы не должны храниться в коде, особенно если репозиторий публичный или доступен широкому кругу разработчиков.
  • Выбор Issue Labels: Прямое следствие ограничений API Linear. Для решения задачи — пометить созданную задачу — подходит только один тип лейблов. Это пример того, как понимание API определяет архитектуру автоматизации.
  • Разделение Reference и Explanation: Само существование двух отдельных документов (данного и (https://app.clickup.com/90152202658/v/dc/2kyquwd2-1815)|референса]]) — это архитектурное решение. Оно позволяет обновлять справочные данные (ID, ключи) без изменения логики, и наоборот — развивать объяснение, не затрагивая конкретные значения.