0.4.11
Поиск по документации… ⌘K
16 · Техническая документация

16. CI/CD и релизы

AstraCode использует GitLab CI/CD для автоматизации сборок и публикации релизов. Архитектура — двухпроектная: сборка в основном репо, бандлы собирает downstream-проект astracode/astra-code-build (его числовой project ID следует уточнить в UI GitLab — конкретное значение здесь приводится как пример).

1. Версионирование

SemVer: MAJOR.MINOR.PATCH. Версия хранится в двух местах и должна быть синхронизирована: - astracode-rs/Cargo.toml ([workspace.package].version) - astracode-cli/package.json ("version")

Job check:version-sync в CI падает, если версии разъехались, а при сборке по тегу — ещё и если тег не совпадает с версией Cargo.toml. Проверка реализована прямо в .gitlab-ci.yml (через awk), отдельного скрипта нет. Job записывает ASTRACODE_VERSION в version.env (dotenv-артефакт для downstream-джобов).

2. Триггеры pipeline

Файл .gitlab-ci.yml лежит в корне репозитория astracode/ (не в astracode-rs/). В нём заданы workflow rules:

yaml
workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'           # пуш в main с изменением Cargo.toml
      changes:
        - astracode-rs/Cargo.toml
    - if: '$CI_PIPELINE_SOURCE == "web"'          # ручной запуск через UI
    - if: '$CI_COMMIT_TAG =~ /^\d+\.\d+\.\d+$/'   # тег SemVer

Pipeline срабатывает: - При пуше SemVer-тега (например 0.4.11). - При изменении astracode-rs/Cargo.toml в main (для проверки version-sync). - Вручную из Web UI.

3. Стадии pipeline

text
check:version-sync       # проверка синхронизации версий Cargo.toml ↔ package.json
       ↓
build:linux-gnu          # cargo build --release --bin astracode
       ↓
publish:package-registry # PUT в Package Registry основного проекта
       ↓
trigger:astra-code-build # вызов downstream pipeline astracode/astra-code-build

check:version-sync

Сравнивает версию из [workspace.package].version (Cargo.toml) и "version" (package.json). Должны совпадать; при сборке по тегу тег тоже должен совпадать с версией.

build:linux-gnu

  • Выполняется на default-runner'е (отдельный image: в .gitlab-ci.yml не задан); toolchain-checks печатают версии rustc/cargo/clang/curl. Сборка использует clang/clang++ (переменные CC/CXX).
  • Команда: cd astracode-rs && cargo build --release --bin astracode (без --target — нативная сборка раннера).
  • Артефакт: astracode-rs/target/release/astracode (с expire_in: 1 week).

В будущем планируются параллельные сборки: - build:linux-musl (статичный бинарник без glibc). - build:macos-arm64. - build:macos-x86_64. - build:windows.

Сейчас macOS-сборки делаются локально и загружаются вручную в Package Registry.

publish:package-registry

Загружает собранный бинарь в Generic Package Registry основного проекта через HTTP PUT. Сначала проверяет, нет ли уже этой версии (HTTP 200 → пропускает), иначе грузит файл:

bash
URL="$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/generic/astracode/$ASTRACODE_VERSION/astracode"
curl --fail --header "JOB-TOKEN: $CI_JOB_TOKEN" \
     --upload-file astracode-rs/target/release/astracode \
     "$URL"

trigger:astra-code-build

Запускает downstream pipeline в проекте astracode/astra-code-build (trigger.project, ветка main, strategy: depend), передавая ASTRACODE_VERSION и ASTRACODE_SOURCE_PROJECT_ID. Downstream: 1. Скачивает свежий бинарник из Package Registry. 2. Упаковывает в platform-specific bundle (с README, LICENSE, npm-wrapper'ом). 3. Загружает финальный бандл в свой Package Registry (откуда тянут пользователи и npm-обёртка).

4. Downstream проект «astra-code-build»

text
https://gitlab.prosto.aib.pro/astracode/astra-code-build (project ID уточнить в UI)

Это публичная точка распространения. У него есть свой Package Registry:

text
https://gitlab.prosto.aib.pro/astracode/astra-code-build/-/packages

Структура пакетов

Имена и версии пакетов ниже приведены как шаблон; актуальный список и платформенные триплеты см. в реальном Package Registry и в scripts/build-release-binaries.py (триплеты: x86_64/aarch64-unknown-linux-musl, x86_64/aarch64-apple-darwin, x86_64/aarch64-pc-windows-msvc).

Package Файл
astracode-linux-x86_64-gnu astracode-linux-x86_64-gnu-0.4.11.tar.gz
astracode-macos (arm64) astracode-macos-0.4.11.zip
astracode-macos-x86_64 astracode-macos-x86_64-0.4.11.zip
astracode-linux-musl astracode-linux-musl-0.4.11.tar.gz
astracode-windows-x86_64 astracode-windows-x86_64-0.4.11.zip

5. Ручная загрузка в Package Registry

Когда CI не отрабатывает (например, для macOS сейчас сборки локальные), загрузка делается вручную:

bash
# Получить персональный access token в Settings → Access Tokens (scope: api)
TOKEN="glpat-..."

# Загрузить файл (<project_id> — числовой ID проекта astra-code-build в GitLab)
curl -k \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --upload-file ./astracode-macos-0.4.11.zip \
  "https://gitlab.prosto.aib.pro/api/v4/projects/<project_id>/packages/generic/astracode-macos/0.4.11/astracode-macos-0.4.11.zip"

Флаг -k — для self-signed certificate GitLab'а.

⚠️ Токены никогда не пушить в репо и сразу отзывать через UI после использования (Settings → Access Tokens → Revoke).

6. Процесс релиза

(пример: выпуск версии 0.4.11 поверх текущей 0.4.11)

text
1. Все правки в main, тесты зелёные
2. Bump версии:
   - sed -i 's/0.4.11/0.4.11/' astracode-rs/Cargo.toml
   - sed -i 's/0.4.11/0.4.11/' astracode-cli/package.json
   - Обновить status snapshot'ы:
     find astracode-rs/tui/src/status/snapshots -name '*.snap' \
       | xargs sed -i 's/AstraCode (v0.4.11)/AstraCode (v0.4.12)/g'
3. git commit -m "Bump version to 0.4.11"
4. git tag 0.4.11
5. git push origin main
6. git push origin 0.4.11
7. Pipeline собирает Linux, публикует в Package Registry
8. Триггерит downstream → собирает финальный бандл
9. Для macOS — сборка локально:
   cargo build --release --target aarch64-apple-darwin --bin astracode
10. Архивируем и грузим вручную (см. п.5)
11. Пишем release notes в CHANGELOG.md
12. (опционально) gh release create / GitLab Release

7. Release notes

В astracode/CHANGELOG.md (в корне репо) ведётся история по версиям на русском, секциями «Добавлено / Изменено / Удалено / Исправлено». Текущая незарелизенная работа — под заголовком «Не выпущено». Шаблон записи:

markdown
## 0.4.11 - <YYYY-MM-DD>

### Добавлено
- ...

### Исправлено
- ...

### Изменено
- ...

См. astracode/CHANGELOG.md для актуальной истории.

8. CHANGELOG генерация

В корне репо есть cliff.toml — конфиг для git-cliff. Генерация:

bash
git-cliff --tag 0.4.11 > CHANGELOG.md

git-cliff читает commit messages и группирует по типам (feat, fix, chore, …).

Conventional commits style:

text
feat(tui): add /help command with pager overlay
fix(locale): allow /locale after /new and /clear
chore(release): bump to 0.4.11

9. Голосование / одобрение релиза

Сейчас нет автоматических голосований — релиз помечает тегом сопровождающий. Для критичных релизов: 1. Создаётся ветка release/0.4.11. 2. PR в main. 3. Минимум 1 reviewer approval. 4. После merge — тегируется.

10. Откат релиза

Если в 0.4.11 нашли блокирующий баг:

bash
# Удалить тег
git tag -d 0.4.11
git push origin :refs/tags/0.4.11

# Удалить пакеты в Registry (через UI или API)
curl -k --header "PRIVATE-TOKEN: $TOKEN" \
  --request DELETE \
  "https://gitlab.prosto.aib.pro/api/v4/projects/<project_id>/packages/<package_id>"

Затем выпустить патч-версию с фиксом и yank-уведомлением в CHANGELOG.

11. npm-пакет

astracode-cli/package.json определяет npm-обёртку. Реальная структура:

json
{
  "name": "@astracode/astracode-cli",
  "version": "0.4.11",
  "license": "Apache-2.0",
  "bin": { "astracode": "bin/astracode.js" },
  "type": "module",
  "files": ["bin", "vendor"]
}

Никакого scripts/postinstall и download-binary.js в обёртке нет. Точка входа — bin/astracode.js (ESM): по process.platform/arch она определяет target-triple, резолвит соответствующий платформенный npm-пакет (@astracode/astracode-cli-linux-x64, -darwin-arm64, -win32-x64, ...) и через spawn запускает вложенный нативный бинарь. То есть бинарники приезжают как зависимости-пакеты под конкретную платформу, а не докачиваются постинсталл-скриптом.

Публикация в npm:

bash
cd astracode-cli
npm publish --access public

(Для on-prem можно публиковать во внутренний Verdaccio.)

12. Безопасность CI

  • CI_JOB_TOKEN — короткоживущий, скоупится на текущий проект.
  • Личные токены (glpat-...) не должны попадать в pipeline (только локально).
  • Подпись бинарников пока не выполняется (рассматривается minisign или GPG).
  • SBOM (Software Bill of Materials) пока не генерируется (рассматривается cargo cyclonedx).

13. Файлы CI

  • .gitlab-ci.yml (в корне репо astracode/) — основной pipeline; version-sync встроен в job check:version-sync (через awk), отдельных shell-скриптов нет
  • scripts/build-release-binaries.py — сборка/стейджинг релизных бинарников по платформам (Python)
  • scripts/stage_npm_packages.py — подготовка npm-пакетов
  • astracode-rs/scripts/setup-windows.ps1 — установка зависимостей для Windows-сборки
  • cliff.toml (в корне репо) — конфиг git-cliff для CHANGELOG
  • astracode-cli/bin/astracode.js — точка входа npm-обёртки (резолвит платформенный пакет и спавнит бинарь)
ESC