Проекты 1С
из терминала

$ curl --proto '=https' --tlsv1.2 -LsSf \
  https://1c-tooling.github.io/eska/install | sh

PS> powershell -ExecutionPolicy Bypass -c \
  "irm https://1c-tooling.github.io/eska/install.ps1 | iex"

Установщик выбирает сборку для текущей ОС и архитектуры, помещает её в ~/.eska/bin и добавляет каталог в PATH. После первой установки откройте новый терминал.

eska --version
eska --help

Установка через Cargo

Если нужен локальный build из исходников, установите стабильный Rust и Cargo:

cargo install eska --locked

Обновление

Повторно выполните установочную команду для своей системы: скрипт скачает последнюю опубликованную версию из GitHub Releases.

Создать и открыть конфиг

eska config init
eska config edit

config init создаёт файл только при его отсутствии. config edit открывает временную копию, проверяет TOML и при сохранении оставляет резервную копию предыдущей версии. Команды выводят фактический путь к файлу; для изолированного окружения каталог можно переопределить через ESKA_CONFIG_DIR.

Автоматический поиск платформы

[build]
runner = "auto"

Сначала eska ищет ibcmd в PATH и стандартных каталогах платформы на основной системе. Если ничего не найдено и задан контейнер, поиск продолжается через Distrobox.

[build]
runner = "host"

[build]
runner = "distrobox"
container = "1c-ubuntu-env"
platform_arch = "x86_64"

Параметры на один запуск

eska platform list
eska platform list --format json
eska build --ibcmd /path/to/ibcmd
eska build --distrobox 1c-ubuntu-env

Приоритет настроек: параметры CLI → ESKA_IBCMD, ESKA_PLATFORM_ARCH, ESKA_DISTROBOX → глобальный конфиг → автоматический поиск. Явный --ibcmd всегда выбирает host runner.

Подключить существующую выгрузку

cd my_configuration
eska init
eska doctor
eska save -m "chore: Подключён проект eska"

В интерактивном терминале тип проекта определяется по XML, а workflow выбирается из списка. Для скрипта задайте workflow явно. По умолчанию исходники ищутся в корне или каталоге src.

eska init --workflow trunk
eska init --source sources/configurator --workflow trunk

Создать каркас

eska new my_configuration
eska new my_extension --type extension --workflow github-flow

В интерактивном терминале первая команда предложит выбрать тип проекта и workflow. new создаёт каталог, eska.toml, Git-настройки и каталог исходников, но не создаёт саму конфигурацию 1С. Существующий каталог не заменяется. Флаг --no-vcs отключает создание Git.

Клонировать готовый проект

eska clone https://example.org/team/my_configuration.git
eska clone ../source-repository my-copy --remote upstream

URL, локальный путь и file:// поддерживаются. Каталог назначения должен отсутствовать; после checkout eska проверяет manifest проекта.

eska.toml standalone-проекта

[project]
type = "configuration"
source = "src"

[build]
platform_version = ""
artifacts_directory = "build"

[vcs.workflow]
preset = "trunk"

source задаётся относительно корня; допустим ., но нельзя выходить наружу через ... Ближайший eska.toml ищется вверх от текущего каталога. Другую точку поиска задаёт глобальный флаг --project-dir.

Корневой eska.toml

[workspace]
members = ["src/sales-report", "src/import-orders"]

[build]
platform_version = "8.3.27.2325"
artifacts_directory = "build"

[vcs.workflow]
preset = "trunk"

Manifest участника

[project]
name = "sales-report"
type = "report"
source = "."

Имя участника обязательно и уникально. Участник может переопределить только build.platform_version; workflow и каталог артефактов принадлежат корню workspace.

Добавить проект

eska new my-orders --type processing

cd src/my-orders
eska init
eska init --name my-orders

Команды можно запускать из корня или любого участника. Новый member создаётся рядом с существующими и автоматически добавляется в workspace.members. Вложенный Git и отдельный workflow не создаются.

Выбор проектов

eska status -p sales-report
eska diff -p sales-report -p import-orders
eska build --workspace
eska version --workspace --format json
eska save -p sales-report
eska save --workspace

-p выбирает участника по имени и допускается несколько раз там, где команда поддерживает группу. --workspace выбирает все проекты и, для status/diff/save, собственные файлы корня. Команды start, switch, finish и history работают со всем репозиторием.

Базовая ветка должна существовать и содержать первый commit. new создаёт начальную main независимо от preset; для Git Flow ветку develop нужно подготовить отдельно.

Использовать master вместо main

[vcs.workflow]
preset = "trunk"

[vcs.workflow.policy]
base_branch = "master"
integration_target = "master"
task_branch_template = "task/{task}"

Доступные поля policy: base_branch, working_branch, task_branch_template, remote, sync_strategy, integration_target, publish, finish и delete_local_branch. Настройки управляют поведением eska, но не переименовывают существующие ветки.

Частично изменить готовый preset

[vcs.workflow]
preset = "custom"
extends = "trunk"

[vcs.workflow.policy]
task_branch_template = "issue/{task}"
remote = "upstream"
delete_local_branch = false

custom должен либо наследовать trunk, github-flow или git-flow, либо содержать полную policy. Ветки release и hotfix в preset Git Flow зарезервированы моделью, но отдельные команды для их создания пока отсутствуют.

eska doctor
eska doctor --format json
eska doctor -p sales-report
eska doctor --workspace

doctor проверяет manifest и корневой XML-дескриптор, требуемую платформу, ibcmd и 1cv8, Git repository и workflow, незавершённые операции Git, автора commit, remote и Git LFS. Remote проверяется без сетевого запроса.

Код завершения — 0, если нет fail, 1 при ошибках окружения и 2 при ошибке аргументов. Успешный doctor не гарантирует, что платформа примет конкретную выгрузку.

1. 1

   Начать задачу

   eska start FI-1234

   Создаёт и активирует task/FI-1234 от базовой ветки. При настроенном remote сначала получает изменения и обновляет базовую ветку только fast-forward; без remote работает локально.

2. 2

   Посмотреть состояние и изменения

   eska status
   eska diff
   eska diff --semantic

   status показывает проект, ветку, задачу и файлы. Обычный diff группирует пути по объектам Конфигуратора; --semantic уточняет изменения модулей, методов, форм и свойств метаданных.

3. 3

   Сравнить версии Git

   eska diff main
   eska diff main --since-branch-point
   eska diff v1.0.0 v1.1.0
   eska diff --raw

   Одна ревизия сравнивается с HEAD, две — друг с другом. --since-branch-point начинает сравнение от общей базы. Сравнение ревизий не включает несохранённые файлы.

4. 4

   Проверить план и сохранить commit

   eska save --dry-run
   eska save
   eska save -m "fix: Исправлен расчёт скидки"
   eska history --limit 20

   --dry-run показывает точный scope, состояния index/worktree и сообщение, но не запускает editor и hooks. Обычный save заново проверяет состояние, включает все неигнорируемые изменения выбранного проекта и создаёт commit.

5. 5

   Переключиться и вернуться

   eska switch --base
   eska switch FI-1234

   switch активирует только существующие локальные ветки. Новую ветку создаёт start. Для start, switch и finish весь Git worktree должен быть чистым; автоматического shelve нет.

6. 6

   Опубликовать и завершить

   git push -u origin task/FI-1234
   # После интеграции PR/MR:
   eska finish

   eska не создаёт PR/MR и не выполняет merge или push. finish проверяет интеграцию, возвращается на базовую ветку и удаляет локальную ветку по policy. После squash/rebase исходный commit может быть недостижим, и консервативная проверка остановит завершение.

eska platform list
eska build --select-platform
eska build
eska build --output build/application.cf

Версия из build.platform_version должна совпасть с найденным ibcmd. Её можно переопределить на один запуск через --platform-version или выбрать интерактивно. Сборка читает текущее состояние диска, включая несохранённые изменения.

Предварительная проверка

eska build --dry-run
eska build --dry-run --format json

Dry run проверяет выбор проектов, пути, коллизии результатов, runner и версию платформы, но не создаёт каталоги, временную базу или артефакты. Обычный build повторяет preflight перед выполнением.

Паспорт сборки

eska build --manifest

Рядом с артефактом появляется <artifact>.manifest.json со схемой 1: тип и SHA-256 результата, версия проекта и платформы, идентификатор снимка исходников, commit и dirty state при наличии Git. Артефакт и паспорт публикуются согласованно; при ошибке прежняя пара сохраняется.

Workspace

eska build -p sales-report
eska build -p sales-report -p import-orders
eska build --workspace

Проекты собираются в порядке members. Общие результаты записываются как build/<project.name>.<ext>. --output разрешён только при выборе одного проекта.

eska patch --dry-run
eska patch --base main --output build/fix.cfe

Patch использует только закоммиченные изменения от общей базы веток до HEAD. Без --base берётся integration_target workflow. Рабочая копия должна быть чистой; существующий .cfe не заменяется.

eska проверяет BSL и применимость в отдельной временной базе, но не выполняет приложение. Для подключения результата безопасный режим расширения должен быть отключён вручную.

eska version
eska version --format json
eska version bump patch
eska version bump minor
eska version bump major

Формат — четыре числовых компонента 1С, не SemVer. Ширина компонентов сохраняется. eska меняет только байты значения версии: BOM, CRLF, отступы и остальной XML остаются прежними. Commit автоматически не создаётся.

eska version --workspace
eska version -p sales-report
eska version -p sales-report bump patch

В workspace читать можно несколько проектов, но bump всегда требует выбрать ровно один.

eska --lang ru status
eska --lang en build --help
eska status --format json
eska diff --semantic --format json
eska diff --raw
NO_COLOR=1 eska status

Язык выбирается через --lang, затем ESKA_LANG, затем локаль ОС. JSON доступен у status, diff, history, doctor, build, patch, version и platform list. Диагностика выводится в stderr.

Наличие изменений в diff не считается ошибкой. При перенаправлении вывода терминальное оформление отключается; непустой NO_COLOR принудительно убирает цвет.