Deploy shared-sqs v0.1.22

2026-04-12 10:08:00 +03:00
parent d7e9d90453
commit d1af612b48
4 changed files with 70 additions and 2 deletions
@@ -281,6 +281,39 @@
 - Не менял SQS auth path для AWS CLI.
 - Не пытался превращать UI в полноценную admin console и пользовательскую console одновременно: для UI выбрал явный user/demo режим с одним tenant-ом.

+---
+# Agent: GitHub Copilot (GPT-5.4)
+
+## Задача: перепроверить live-стенд и довести deploy до рабочего состояния
+
+### Что проверял
+После жалобы на `invalid JWT: expected 3 parts, got 1` я не стал объяснять по памяти, а перепроверил три вещи по факту:
+
+1. В `main` уже есть demo UI код.
+2. В кластере реально был запущен образ `naeel/shared-sqs:v0.1.21`.
+3. Live `POST /ui/api/auth` на demo token действительно отвечал старой JWT-ошибкой.
+
+### Вывод
+Проблема была не в коде ветки и не в браузере, а в том, что стенд ещё не был выкатан на новый образ.
+
+### Что сделал
+1. Обновил version surfaces до `v0.1.22` в deploy/helm файлах.
+2. Собрал и запушил `naeel/shared-sqs:v0.1.22`.
+3. Попытался выкатить через Helm.
+4. Helm upgrade упёрся в field-manager conflict на поле image (`kubectl-set` vs Helm).
+5. Чтобы не тратить время на долгую reconcile-разборку прямо посреди проверки стенда, переключил live deployment через `kubectl set image`.
+6. Дождался успешного rollout.
+7. Перепроверил live demo auth и потом прогнал `bash tests/quick_test.sh` против `https://qu.kube5s.ru`.
+
+### Итог
+- live deployment теперь на `naeel/shared-sqs:v0.1.22`;
+- demo token работает;
+- реальный JWT flow не сломан;
+- `quick_test.sh` дал `31/31 PASS`.
+
+### Почему этот путь был правильным
+Пользователь явно потребовал не рассказывать, а сначала всё перепроверять и доводить до рабочего состояния. Поэтому после обнаружения расхождения между `main` и live-стендом я не остановился на объяснении, а довёл цепочку до фактического результата на боевом endpoint.
+
 ---

 ## Внешние ссылки для возврата к теме 64KB+