Загрузка данных
Работаем в project-manager-tools.
Контекст:
Перед исследованием blocker нужно проверить, что финальная версия проекта полностью осталась рабочей на реальных SberTrack API запросах.
Уже ранее было подтверждено:
- create release работает
- create epic работает
- create story работает
- create task работает
- create bug работает
- create links работает
- PATCH/update работает
- remote search по summary работает
- cache работает
- sbertrack_write_enabled после тестов должен возвращаться в false
Сейчас задача:
Провести полный контрольный тест финальной версии проекта на реальных запросах SberTrack, но БЕЗ blocker.
ВАЖНО:
- blocker НЕ создавать
- blocker НЕ тестировать
- blocker endpoint НЕ дергать
- DELETE не выполнять
- PUT не выполнять
- git push не выполнять
- секреты не выводить
- полный .env не выводить
- после теста обязательно вернуть sbertrack_write_enabled=false
- все реальные POST/PATCH выполнять только для нового тестового набора сущностей
- название тестового релиза сделать уникальным, чтобы не конфликтовать со старым testic
Тестовый summary:
Используй уникальный summary формата:
final-check-YYYYMMDD-HHMM
Например:
final-check-20260710-001
Не используй старый testic, чтобы не путать с уже созданным TST123456-41.
Порядок проверки:
## 1. Проверить окружение
Показать:
- текущую директорию
- что это project-manager-tools
- доступен ли API
- GET /rest/api/user/v1/current-info возвращает HTTP 200
- GET /rest/api/space/v3/TST123456 возвращает HTTP 200
- пользователь определился
- sbertrack_project_key = TST123456
- sbertrack_write_enabled в начале = false
Не выводить:
- token
- password
- username/password целиком
- полный .env
Можно показать только безопасные ключи:
- sbertrack_base_url
- sbertrack_project_key
- sbertrack_write_enabled
## 2. Проверить синтаксис
Выполнить:
python -m py_compile src/sbertrack_api.py src/sbertrack_planner.py src/unit_cache.py src/main.py src/yaml_reader.py
Если есть ошибки — остановиться, показать ошибку и НЕ выполнять реальные POST.
## 3. Подготовить тестовый YAML
Создать отдельный тестовый YAML файл в безопасном месте проекта, например:
projects/luch/services/luch-pprb/releases/release-final-check-YYYYMMDD-HHMM.yaml
В YAML должны быть заполнены все обязательные поля, чтобы release не был пустым.
Структура должна включать:
1. release:
- summary: final-check-YYYYMMDD-HHMM
- description: "Final integration check from project-manager-tools. Safe to delete."
- space: TST123456
- ci_code: CI02298102
- priority: low
- workflow_status: {"command": "NEW"}
- release_kind: planned
- uat_ground: hotfix
- conditions_itservice: dontChange
- without_integration: false
- omni: false
- uat_start_date: ISO datetime
- introduction_start_date: ISO datetime
2. epic:
- summary: final-check-YYYYMMDD-HHMM epic
- description: "Final check epic"
3. stories:
- final-check-YYYYMMDD-HHMM story 1
- final-check-YYYYMMDD-HHMM story 2
4. tasks:
- final-check-YYYYMMDD-HHMM task 1
- final-check-YYYYMMDD-HHMM task 2
- final-check-YYYYMMDD-HHMM task 3
5. bug:
- final-check-YYYYMMDD-HHMM bug 1
Не добавлять blocker.
## 4. Dry-run перед реальным запуском
Выполнить dry-run:
- safe plan
- ensure dry-run
- cache status
Проверить:
- YAML найден
- payload полный
- обязательные поля есть
- planned сущности отображаются
- реальные POST/PATCH/DELETE на dry-run не выполнялись
Если dry-run не прошел — остановиться и НЕ включать write_enabled=true.
## 5. Реальный create full release
Только после успешного dry-run:
1. Временно установить:
sbertrack_write_enabled=true
2. Выполнить реальный create/ensure full release по тестовому YAML.
Должно создаться:
- 1 Release
- 1 Epic
- 2 Story
- 3 Task
- 1 Bug
Для каждой сущности показать таблицу:
Тип сущности | Summary | Endpoint | HTTP status | Created code
Ожидаемые endpoints:
- POST /rest/api/unit/v2/release/create
- POST /rest/api/unit/v2/epic/create
- POST /rest/api/unit/v2/story/create
- POST /rest/api/unit/v2/task/create
- POST /rest/api/unit/v2/bug/create
Ожидаемые HTTP:
- 200 или 201
Если что-то не создалось:
- показать ошибку
- НЕ продолжать links
- вернуть sbertrack_write_enabled=false
## 6. Реальное создание links
После успешного создания всех сущностей создать связи.
Проверить, что используются актуальные created code, а не старые TST123456-41/42/...
Создать связи:
- story 1 -> release
- story 2 -> release
- task 1 -> release
- task 2 -> release
- task 3 -> release
- epic -> release
- story 1 -> epic
- story 2 -> epic
- task 1 -> story 1
- task 2 -> story 1
- task 3 -> story 2
- release -> bug
Типы связей использовать только уже подтвержденные:
- release
- decomposition
- containsbug
Endpoint:
- POST /rest/api/unit/v1/link
Показать таблицу:
Source | Destination | Link type | HTTP status | Result
Ожидаемые HTTP:
- 201
- если HTTP 570 "уже существует" — считать ожидаемым только если это повторный запуск на тех же сущностях
## 7. Проверить remote search по summary
Проверить поиск созданного release по summary без опоры только на cache.
Нужно:
1. Временно изолировать или удалить только cache-запись для нового release summary.
2. НЕ трогать остальные cache-записи.
3. Выполнить find_unit_by_summary для нового summary.
4. Убедиться, что поиск идет через SberTrack API:
POST /rest/api/unit/v2/find
или подтвержденный метод sbertrack_python_api.client.unit.find
5. Ожидаемый HTTP status: 200
6. Ожидаемый результат: найден code созданного release.
7. После поиска запись должна вернуться в cache.
Показать:
- cache miss был: да/нет
- endpoint поиска
- HTTP status
- найденный code
- cache после поиска содержит запись: да/нет
## 8. Проверить PATCH/update на новом release
Выполнить реальный PATCH только для созданного нового release.
Обновить только безопасное поле:
- description
Новое значение:
"Final integration check PATCH update from project-manager-tools. Existing release updated safely. Safe to delete."
Endpoint:
- PATCH /rest/api/unit/v2/update/{created_release_code}
Показать:
- code
- endpoint
- HTTP status
- старое значение description
- новое значение description
- GET после PATCH подтверждает обновление: да/нет
НЕ менять:
- summary
- type
- project/space
- issue type
- связи
- workflow/status
- даты, если это рискованно
## 9. Проверить ensure на уже существующем release
После PATCH повторно запустить ensure для того же summary.
Ожидаемое поведение:
- дубль НЕ создается
- сначала cache/search находит существующий release
- выполняется update существующего release
- возвращается тот же code
- created code не меняется
Показать:
- старый code
- code после повторного ensure
- совпадают: да/нет
- дубль создан: нет
## 10. Вернуть безопасный режим
В конце обязательно:
1. Вернуть:
sbertrack_write_enabled=false
2. Проверить grep только безопасных ключей:
- sbertrack_write_enabled
- sbertrack_project_key
- sbertrack_base_url
3. Подтвердить:
- полный .env не выводился
- секреты не выводились
- git push не выполнялся
- DELETE не выполнялся
- PUT не выполнялся
- blocker не создавался
- sbertrack_write_enabled=false в конце
## 11. Финальный отчет
Вывести отчет:
# ФИНАЛЬНЫЙ ОТЧЕТ ПРОВЕРКИ ФИНАЛЬНОЙ ВЕРСИИ
## 1. Окружение
- API доступен: да/нет
- current-info HTTP:
- space HTTP:
- project key:
- пользователь:
- write_enabled в начале:
- write_enabled в конце:
## 2. Синтаксис
- py_compile: успешно/ошибка
## 3. YAML
- файл:
- summary:
- payload полный: да/нет
## 4. Dry-run
- safe plan: успешно/ошибка
- ensure dry-run: успешно/ошибка
- реальные запросы на dry-run: нет
## 5. Create
Таблица:
Тип | Summary | Endpoint | HTTP | Code
## 6. Links
Таблица:
Source | Destination | Type | HTTP | Result
## 7. Remote search без cache
- cache miss подтвержден:
- endpoint:
- HTTP:
- найден code:
- cache восстановлен:
## 8. PATCH/update
- endpoint:
- HTTP:
- обновлен code:
- GET после PATCH подтверждает обновление:
## 9. Ensure без дублей
- повторный ensure вернул тот же code:
- дубль создан:
- итог:
## 10. Безопасность
Подтвердить:
- sbertrack_write_enabled=false
- DELETE не выполнялся
- PUT не выполнялся
- blocker не создавался
- git push не выполнялся
- секреты не выводились
- полный .env не выводился
## 11. Итог
Сказать честно:
- финальная версия проекта полностью рабочая: да/нет
- что работает на реальных API:
- create release
- create epic
- create story
- create task
- create bug
- create links
- remote search
- PATCH/update
- ensure без дублей
- что осталось отдельно:
- blocker model/endpoint исследовать read-only следующим шагом