Закрывает эту тему окончательно. После merge в main CI анализирует
conventional commits с последнего tag'а, бампит package.json + CHANGELOG.md
и пушит git tag vX.Y.Z. Tag pipeline далее собирает images и ждёт
manual gate на trigger-deploy-prod.
Что добавил:
- ordinis-admin-ui/.releaserc.json — config (commit-analyzer, release-notes,
changelog, npm[no-publish], git, gitlab). branches: ['main']. Маппинг
conventional-commit types к bump levels.
- ordinis-admin-ui/package.json — devDeps: semantic-release@24.2 + 6 plugins.
- .gitlab-ci.yml — new 'release' stage + release job:
- needs: trigger-deploy-staging (release ТОЛЬКО после зелёного staging)
- image: node:22-alpine + pnpm@9.15.4
- GL_TOKEN из CI variable GITLAB_TOKEN (semantic-release/gitlab требует
именно GL_TOKEN env name)
- allow_failure: true (нет релизных commits = OK, не блокирует pipeline)
- RELEASE.md — operator docs:
- One-time setup: создать Project Access Token + GITLAB_TOKEN CI var
- Commit conventions table (feat→minor, fix→patch, breaking→major)
- Skip release (use chore: type или [skip ci])
- Dry-run command для local validation
Prod safety: trigger-deploy-prod остаётся manual (when: manual). Автоматизация
ТОЛЬКО tag-создания, не deploy. Tag → CI runs → human кликает Deploy.
ACTION REQUIRED от user (one-time):
1. GitLab → Settings → Access Tokens → создать Project Access Token
scopes: write_repository + api, role: Maintainer
2. GitLab → Settings → CI/CD → Variables → GITLAB_TOKEN (Masked, Protected)
Без этого release job будет fail'ить (но pipeline не покраснеет — allow_failure).
Zimin A.N.