mirror of
https://github.com/azaion/ui.git
synced 2026-06-21 23:41:10 +00:00
Oleksandr Bezdieniezhnykh
15838c5cc1
ci/woodpecker/push/build-arm Pipeline failed
- Changed current step from 15 (Performance Test) to 9 (New Task) in _docs/_autodev_state.md, reflecting the transition to Cycle 3. - Updated cycle count from 2 to 3 and modified sub-step details to indicate progress in gathering feature descriptions. - Added new lessons to _docs/LESSONS.md, emphasizing best practices for API key management, dependency handling, and reporting inline fixes during security audits. - Enhanced CI/CD pipeline documentation in _docs/02_document/deployment/ci_cd_pipeline.md to include new gates for vulnerability scans and SBOM emissions, along with dependency overrides for transitive dependencies. - Expanded environment strategy documentation in _docs/02_document/deployment/environment_strategy.md to include the new Google Geocode API key management. Co-authored-by: Cursor <cursoragent@cursor.com>
100 lines
4.9 KiB
Markdown
100 lines
4.9 KiB
Markdown
# Cycle 2 Step 16 — Deferred deploy + manual revocations
|
||
|
||
**Created**: 2026-05-12T01:44:00Z (autodev Step 16, planning-only outcome)
|
||
**Cycle**: 2
|
||
|
||
This file tracks deploy-related work that could not complete this cycle because each
|
||
item depends on action outside this workspace.
|
||
|
||
---
|
||
|
||
## L-AZ-498-DEPLOY — UI tile-swap prod cutover (cross-workspace gate)
|
||
|
||
**What is blocked**: prod deploy of the UI changes from cycle 2 batch 11 that route
|
||
the map's `<TileLayer>` through the suite's own `satellite-provider` (`/tiles/{z}/{x}/{y}`)
|
||
with same-origin cookie auth. The image will build cleanly today (the source change is in
|
||
`dev`), but cutting prod traffic over before satellite-provider's auth migration lands
|
||
will break the map for all users.
|
||
|
||
**Cross-workspace prerequisite**: a separate AZAION ticket on the **satellite-provider**
|
||
workspace must publish a cookie-auth variant of `GET /tiles/{z}/{x}/{y}` AND deploy that
|
||
change to all environments the UI is promoted into (dev / stage / prod). Today the UI
|
||
sets `crossOrigin="use-credentials"` on tile images, but the server still expects an
|
||
`Authorization: Bearer ...` header (which Leaflet `<img>` requests cannot send).
|
||
|
||
**Replay procedure** (run at the start of the next cycle's Step 16, or sooner on user
|
||
request):
|
||
|
||
1. Verify the satellite-provider workspace has merged the cookie-auth change to dev,
|
||
stage, and main equivalents.
|
||
2. Verify the satellite-provider deploys are live in each environment (smoke check:
|
||
`curl --cookie ... https://<host>/tiles/0/0/0` returns 200 with `Content-Type: image/jpeg`).
|
||
3. Run the UI tile-render smoke check: `bunx playwright test e2e/tests/infrastructure.e2e.ts -g "tile"`
|
||
against each environment.
|
||
4. Build + push the UI image (the Woodpecker pipeline already does this on every `dev`
|
||
push; cycle 2 commit `f7dd6c9` is on `dev` as of 2026-05-12).
|
||
5. Promote: `dev → stage → main` per the standard branch model
|
||
(`_docs/02_document/deployment/ci_cd_pipeline.md` §1).
|
||
6. Post-deploy verification: load `/flights` on each environment, pan the map, watch
|
||
network panel — every `/tiles/...` request returns 200 and the request is sent with
|
||
the auth cookie attached.
|
||
|
||
**Escalation**: if the satellite-provider ticket is still not landed by the next cycle's
|
||
Step 16 review, surface to the user via Choose A/B/C/D — the gate cannot be silently
|
||
bypassed because doing so produces a visibly broken map in production.
|
||
|
||
---
|
||
|
||
## L-AZ-499-OWM-REVOKE — OpenWeatherMap key revocation
|
||
|
||
**What is blocked**: closing AZ-499 acceptance criterion AC-7 (and the equivalent
|
||
project-wide AC-42), which requires the OWM key `335799082893fad97fa36118b131f919`
|
||
that was previously committed to the repo to be revoked at the OWM dashboard.
|
||
|
||
**Why this can't be done from this workspace**: revocation requires authenticated
|
||
access to `https://home.openweathermap.org/api_keys` — a third-party UI that cannot
|
||
be automated from CI without storing OWM credentials, which is out of scope.
|
||
|
||
**Replay procedure** (manual, requires user):
|
||
|
||
1. Sign into `https://home.openweathermap.org/api_keys`.
|
||
2. Locate the key `335799082893fad97fa36118b131f919`.
|
||
3. Disable / regenerate / delete it. Capture evidence: dashboard screenshot OR a
|
||
timestamped URL showing the key is no longer active.
|
||
4. Attach the evidence to Jira ticket **AZ-499** (or to the parent epic if the user
|
||
prefers).
|
||
5. Transition AZ-499 to **Done** in Jira.
|
||
6. Delete this leftover entry once steps 1–5 are complete.
|
||
|
||
**Compensating control already in place**: `STC-SEC1C` (in `scripts/check-banned-deps.mjs`
|
||
+ `tests/security/banned-deps.json`) prevents the literal value from re-entering the
|
||
source tree.
|
||
|
||
---
|
||
|
||
## L-AZ-501-GOOGLE-REVOKE — Google Geocode key revocation
|
||
|
||
**What is blocked**: closing AZ-501 acceptance criterion AC-6 (and the project-wide
|
||
AC-43), which requires the Google Geocode key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`
|
||
that was previously committed in `mission-planner/src/config.ts` to be revoked at the
|
||
Google Cloud Console.
|
||
|
||
**Why this can't be done from this workspace**: same reason as AZ-499 — revocation
|
||
requires authenticated access to `https://console.cloud.google.com/google/maps-apis/credentials`,
|
||
which cannot be automated.
|
||
|
||
**Replay procedure** (manual, requires user):
|
||
|
||
1. Sign into `https://console.cloud.google.com/google/maps-apis/credentials`.
|
||
2. Locate the key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`.
|
||
3. Restrict the key to no APIs / no referrers (effectively revoke) OR regenerate it.
|
||
Capture evidence: dashboard screenshot OR a timestamped URL showing the
|
||
restriction.
|
||
4. Attach the evidence to Jira ticket **AZ-501**.
|
||
5. Transition AZ-501 to **Done** in Jira.
|
||
6. Delete this leftover entry once steps 1–5 are complete.
|
||
|
||
**Compensating control already in place**: `STC-SEC1D` (registered in `scripts/run-tests.sh`
|
||
under `run_static`, with the literal in `tests/security/banned-deps.json` →
|
||
`google_key_in_source`) prevents the literal value from re-entering the source tree.
|