little-spark-kit 0.1.6 → 0.1.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.MD +50 -1
- package/package.json +1 -1
package/README.MD
CHANGED
|
@@ -1 +1,50 @@
|
|
|
1
|
-
|
|
1
|
+
# DevOps CI/CD Challenge: Автоматизированный пайплайн релизов
|
|
2
|
+
|
|
3
|
+
Этот проект реализует полностью автоматизированный (zero-touch) CI/CD пайплайн для TypeScript npm-пакета. Основной фокус проекта — надежный жизненный цикл релиза, использование GitHub Actions, Label-Driven логики и лучших практик GitOps.
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
----
|
|
7
|
+
|
|
8
|
+
## 🏗 Архитектура: Разделение на два репозитория
|
|
9
|
+
|
|
10
|
+
Для соблюдения принципа DRY (Don't Repeat Yourself) и выполнения требования задания по вынесению переиспользуемых шагов, инфраструктура разделена на два репозитория:
|
|
11
|
+
|
|
12
|
+
1. **[code-repo](https://github.com/kirylzhan-stack/code-repo):** Основной репозиторий, содержащий исходный код и зависимости TypeScript-приложения а так же входные точки рабочих процессов (`main-workflow`, `release-on-merge.yml`).
|
|
13
|
+
2. **[cicd-repo](https://github.com/kirylzhan-stack/cicd-repo):** Централизованная библиотека кастомных Composite Actions (`branch-protection`, `build-and-test`, `e2e-tests`, `publish`).
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 🔄 CI Pipeline: Проверка Pull Request (`pr.yml`)
|
|
18
|
+
|
|
19
|
+
При открытии или обновлении Pull Request запускается основной CI-процесс:
|
|
20
|
+
|
|
21
|
+
1. **Автоматизация Branch Protection:** Скрипт через GitHub API (`gh api`) жестко задает правила для ветки `main`: требует линейную историю (`required_linear_history`) и прохождение обязательных проверок (`strict: true`), гарантируя, что ветка всегда обновлена (up-to-date with main). Разрешает авто-мерж.
|
|
22
|
+
2. **Build & Test:** Запускает `npm ci` (гарантируя блокировку зависимостей через `package-lock.json`), линтинг, сборку проекта и юнит-тесты.
|
|
23
|
+
3. **Контроль параллелизма (Concurrency):** Настроен механизм `concurrency`, который автоматически отменяет устаревшие пайплайны при одновременном добавлении нескольких лейблов. Это предотвращает состояние гонки (race conditions) и экономит минуты раннеров.
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 🏷 Label-Driven Workflow (Работа с метками)
|
|
28
|
+
|
|
29
|
+
Поведение пайплайна динамически меняется в зависимости от навешенных на PR меток.
|
|
30
|
+
|
|
31
|
+
### 1. Метка `verify`
|
|
32
|
+
Добавление метки `verify` запускает изолированные **End-to-End (E2E) тесты**.
|
|
33
|
+
* **Как это работает:** Вместо простого тестирования исходников, пайплайн поднимает локальный npm-реестр **Verdaccio**. Проект собирается, публикуется в этот локальный реестр, после чего симулируется поведение реального пользователя: создается пустой проект, выполняется `npm install <package>` и запускается тестовый скрипт, импортирующий библиотеку.
|
|
34
|
+
* **Зачем:** Это на 100% гарантирует, что скомпилированная папка `dist/` и пути в `package.json` настроены корректно перед слиянием с `main`.
|
|
35
|
+
|
|
36
|
+
### 2. Метка `publish`
|
|
37
|
+
Добавление метки `publish` работает как Pre-Release проверка и генерирует Release Candidate (RC).
|
|
38
|
+
* **Валидация версии:** Сравнивает версию `package.json` в PR с версией в ветке `main`, чтобы убедиться, что разработчик явно поднял версию.
|
|
39
|
+
* **Проверка глобального реестра:** Делает запрос `npm view`, чтобы заблокировать сборку, если такая версия уже опубликована в npm.
|
|
40
|
+
* **Release Candidate артефакт:** Временно меняет версию "на лету" с добавлением суффикса (например, `1.0.1-dev-<short_sha>`) через `--no-git-tag-version`, собирает проект и сохраняет артефакт.
|
|
41
|
+
|
|
42
|
+
## 🚀 CD Pipeline: Релиз после слияния (`release-on-merge.yml`)
|
|
43
|
+
|
|
44
|
+
Этот рабочий процесс отвечает за финальную доставку и запускается **исключительно** при закрытии и успешном слиянии Pull Request (`merged == true`), если на нём была установлена метка `publish`.
|
|
45
|
+
|
|
46
|
+
Для обеспечения чистоты финального релиза и строгого следования семантическому версионированию применяется следующая логика:
|
|
47
|
+
|
|
48
|
+
1. **Извлечение чистой версии (Version Init):** Воркфлоу забирает итоговый код прямо из целевой ветки (base ref) после слияния. Затем с помощью утилиты `jq` он динамически извлекает финальную, "чистую" версию пакета из `package.json` и сохраняет её в переменные окружения.
|
|
49
|
+
2. **Автоматическая публикация в npm:** Перед публикацией выполняется подготовка манифеста (скрипт `prepare` безопасно удаляется из `package.json`, чтобы избежать конфликтов жизненного цикла npm в CI-среде). После настройки токена авторизации пакет публикуется в публичный реестр (`npm publish --access public`).
|
|
50
|
+
3. **Git Tag и GitHub Release:** С помощью встроенной интеграции GitHub CLI (`gh release create`) система автоматически создает Git-тег (например, `v1.0.1`) и формирует полноценный релиз в интерфейсе GitHub. В описание релиза автоматически подтягиваются заголовок смерженного PR, его номер и автоматически сгенерированный Changelog (благодаря флагу `--generate-notes`).
|