Git-синхронизация — автотесты живут в git

Привяжите коллекцию автотестов к git-репозиторию. Mockarty тянет тесты из
репозитория (они появляются готовыми к запуску) и отправляет обратно то, что
вы записали или отредактировали. Браузерные тесты команды лежат в git рядом с
кодом приложения, ревьюятся в pull request’ах и раскатываются на всех
автоматически.

Git-синхронизация бесплатна — часть базового продукта на всех тарифах.

Зачем

• Единый источник истины. Тесты лежат в вашем репозитории, версионируются и
  ревьюятся как код — не заперты внутри одного инструмента.
• Появляются сами. Настройте репозиторий в Mockarty один раз; фоновая
  синхронизация держит Mockarty каждого коллеги свежим с тем, что закоммичено.
• Запись в браузере, коммит из Mockarty. Запишите сценарий (без
  Playwright-инспектора) и отправьте его прямо в репозиторий.
• Работает везде. Desktop, on-prem и cloud читают одну привязку, так что одни
  и те же тесты доступны, где бы вы ни работали.

Быстрый старт (UI)

Откройте Настройки → Git-синхронизация → Добавить привязку:

Затем действия в строке: Тянуть (забрать изменения из репозитория),
Отправить (опубликовать свои изменения), Удалить (отвязать — уже
синхронизированные тесты остаются в Mockarty).

Несколько устройств, один репозиторий

Один репозиторий можно привязать сразу в нескольких местах — ваш Desktop,
Desktop коллеги, общий Mockarty и люди, которые правят файлы напрямую.
Синхронизация работает как слияние в git, поэтому ничья работа не затирается:

• Тянуть забирает то, что изменилось в репозитории с вашей прошлой
  синхронизации. Ваши правки, которые вы ещё не отправили, остаются как есть.
• Отправить публикует ваши изменения одним коммитом. Если репозиторий тем
  временем изменился, эти изменения сохраняются и приходят к вам.
• Файл, удалённый на одной стороне, удаляется и на другой — и не возвращается при
  следующей синхронизации.
• Файл, по-разному изменённый на обеих сторонах, — это конфликт. Ничего не
  записывается, пока вы не решите: окно показывает каждый такой файл — вашу
  версию против версии репозитория построчно, — и для каждого файла вы выбираете
  Оставить мою или Взять из репозитория, затем Применить решения.
  Отмена оставляет обе стороны нетронутыми.

Из CLI (удобно для CI)

# привязать репозиторий
mockarty-cli git-sync add \
  --repo https://github.com/you/tests.git \
  --kind ui --subdir mockarty --token "$GIT_PAT"

# список привязок (со статусом последней синхронизации)
mockarty-cli git-sync list

# подтянуть свежие тесты, затем прогнать их
mockarty-cli git-sync pull <binding-id>

# отправить записанное обратно
mockarty-cli git-sync push <binding-id> --message "обновил логин-флоу"

--output json печатает машиночитаемый вывод для пайплайнов.

В пайплайне конфликт останавливает команду с ненулевым кодом и списком файлов.
Решите их прямо в команде и запустите снова:

# оставить версию пайплайна для одного файла
mockarty-cli git-sync push <binding-id> --resolve uitests/login-flow.json=local

# взять версию репозитория для всех конфликтующих файлов
mockarty-cli git-sync pull <binding-id> --prefer remote

Из SDK

from mockarty import MockartyClient

client = MockartyClient(base_url="http://localhost:5770", api_key="mk_...")

b = client.git_sync.create_binding(
    "https://github.com/you/tests.git",
    kind="ui", subdir="mockarty", auth_token="ghp_…",
)
result = client.git_sync.pull(b["id"])          # {"commit": "...", "uiTestsFound": 12}
client.git_sync.push(b["id"], "обновил тесты")  # коммит правок обратно

Go и Java дают те же операции (client.GitSync() / client.gitSync()).

Для ИИ-агента

Агент может держать себя в синхроне с репозиторием:

• git_sync_list_bindings — найти привязанный репозиторий и его id
• git_sync_pull — материализовать свежие тесты перед прогоном сьюта
• git_sync_push — закоммитить записанные тесты обратно в репозиторий

Если файл изменён на обеих сторонах, вызов отвечает списком конфликтующих файлов
с обеими версиями; агент показывает их вам или передаёт своё решение
(resolutions: local или remote для каждого файла) в том же вызове ещё раз.

В кабинете окно конфликта позволяет переходить между файлами и сравнивать
обе версии до применения выбора. Решение привязано именно к показанным
версиям репозитория и локального файла. Если за время просмотра одна из сторон
изменилась, сервер отклонит старое решение с 409: просмотрите свежий конфликт,
чтобы не затереть правку, которую вы ещё не видели.

Если вы пишете REST-клиент для общего репозитория, отправляйте вместе с
resolutions поля expectedBaseCommit и expectedRemoteCommit из ответа
409. Для каждого выбранного пути скопируйте inBase, inLocal, inRemote,
baseDigest, localDigest и remoteDigest в expectedConflicts[path].
Решение только по пути принимается для совместимости со старыми клиентами,
но не защищает от параллельного изменения; не используйте его при совместной
работе.

Владелец или администратор может привязать репозиторий в интерфейсе либо
через инструмент агента git_sync_create_binding. Для частного репозитория
используйте токен с минимальными правами; после привязки его нельзя прочитать.

Как выглядит репозиторий

Тесты хранятся как небольшие, чистые для diff файлы — по одному на тест — так что
изменение = читаемый однофайловый diff и ревью простое:

<подкаталог>/
  uitests/
    _manifest.json
    checkout.json
    login-flow.json

Каждый файл держит имя теста, платформу и записанные шаги. Эфемерные детали (id,
метки времени, скриншоты) не пишутся, чтобы файлы оставались стабильными между
синхронизациями.

Дайте UI-тестам в одном Пространстве названия, которые превращаются в разные
имена файлов. Например, Login flow и login-flow попадут в одно имя файла.
Git-синхронизация остановится с понятной ошибкой проверки, а не станет
угадывать, какой файл обновить. Переименуйте один из тестов и повторите
попытку; при таком отказе тесты не удаляются. Если совпадают имена файлов у тестов с названиями только
на кириллице, добавьте к каждому названию разное латинское слово или число.

Wiki-страницы (kind = wiki)

Привязка Wiki хранит страницы как wiki/<путь-страницы>.md. Если страницу
нельзя прочитать, иерархия родителей повреждена или две страницы попадают в
один путь файла, синхронизация сообщает об ошибке, а не публикует неполную
Wiki. Исправьте страницы и повторите попытку.

Доски (kind = boards)

Привязка досок хранит каждую доску как boards/<имя>.excalidraw.json.
Названия должны давать разные имена файлов. Если две доски попадают в один
файл, а импортируемый файл повреждён или его не удаётся сохранить,
синхронизация сообщает об ошибке. Исправьте доску или файл и повторите
попытку: такую ревизию нельзя считать успешно импортированной.

Тест-кейсы как код (kind = tcm)

Привязка с типом Тест-кейсы (as code) хранит кейсы TCM как markdown-файлы
с YAML-шапкой — один файл на кейс, папки становятся директориями:

<subdirectory>/
  tcm/
    auth/
      login-works.md
    checkout.md

---
id: 5f6a…                # стабильный id кейса (повторный pull идемпотентен)
name: Логин работает
priority: high
tags: [smoke, auth]
customFields:
  Component: Auth
steps:
  - action: Открыть /login
    expected: Видны поля email и пароль
    data: user=admin
---
Свободное описание кейса (markdown).

• Push выгружает каталог кейсов пространства — изменения кейсов ревьюятся
  в pull request’ах, как обычный код.
• Pull применяет правки из файлов: файл с совпавшим id обновляет кейс
  (метаданные, кастом-поля; шаги получают новую версию только если реально
  изменились), новый файл создаёт кейс в папке по своей директории. Файл без
  id сопоставляется по имени — коллега может завести кейс целиком в
  редакторе.
• Автоматизированные шаги остаются автоматизированными. Формат файла
  описывает шаг так, как его читает человек: имя, действие, ожидаемый результат,
  тестовые данные. У шага, который выполняется сам, есть ещё настройки запуска
  (что он вызывает, что проверяет, что передаёт дальше) — их файл не хранит.
  Если вы поправите текст такого кейса в репозитории и заберёте изменения
  обратно, настройки запуска в Mockarty сохранятся: файл решает, как написано,
  Mockarty хранит остальное. Одна тонкость: шаг узнаётся по имени и действию,
  поэтому если переписать само действие, шаг считается новым и вернётся ручным —
  настройки запуска нужно задать заново в интерфейсе.

Приватные репозитории и токены

• Используйте personal access token с правом чтения репозитория (для pull) и
  записи (для push). Подходят GitHub ghp_…, GitLab glpat-… и app-пароли
  Bitbucket.
• Токен никогда не возвращается API и не показывается в UI — только индикатор
  «токен сохранён» — и хранится зашифрованным, если настроен ключ
  шифрования PII платформы.
• Принимаются только https URL репозитория, а URL, указывающий на приватный
  или внутренний адрес, отклоняется.

Полезно знать

Привязанная к Git коллекция API-тестера синхронизируется так же: её
неотправленные правки переживают подтягивание, а запрос, изменённый на обеих
сторонах, показывается вам для решения. Коллекция сохраняется одной операцией —
если сохранить любой запрос не удалось, прежнее содержимое остаётся. Доступ только на чтение не разрешает подтягивание, отправку, изменение
или удаление Git-привязки — нужны права редактирования. Если привязка изменилась
во время подтягивания, повторите его с текущими настройками подключения.

• Pull идемпотентен — повторное подтягивание того же репозитория обновляет
  существующие тесты и страницы, а не создаёт дубликаты.
• Удаление привязки останавливает синхронизацию, но оставляет тесты, уже
  загруженные в Mockarty.
• Авто-синхронизация тянет по расписанию, так что закоммиченные тесты
  появляются без ручного pull. Отключается для каждой привязки, если вы
  предпочитаете ручные pull’ы.

Связанное

• Запись UI-тестов — записывайте тесты для синхронизации
• Миграция с Playwright
• Миграция с Cypress
• Руководство по SDK