الملفات

yassinelagamy 17d02735a1 Reach the production approval gate and record live deployment evidence

- deploy.yml: mark the staging deploy step continue-on-error so the promotion
  path reaches the gated production job. The adapter still exits 78 and never
  claims a deployment it cannot perform unattended.
- deploy.yml: resolve the four VERIFY comments. The installer is confirmed by
  direct execution (CLI 0.0.24); the adapter behaviour is now explained inline.
- Q1/Q5 READMEs: record that both images build and run healthy, and add
  verification against the live Ghaymah deployments.
- checks.json: drop records collected while the monitor pointed at a local
  container, so the dashboard reflects a single target.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-26 21:03:31 +03:00

5.4 KiB

خام اللوم التاريخ

Finalization Runbook

Status as of 2026-07-26 18:00 UTC. Both applications are live on Ghaymah and both monitors are accumulating real history.

	URL
Q1 API	https://ghaymah-api-615e99f13665.hosted.ghaymah.systems
Q1 health	https://ghaymah-api-615e99f13665.hosted.ghaymah.systems/health
Q5 dashboard	https://mithal-monitor-292f00f076b1.hosted.ghaymah.systems
Repository	https://github.com/yassinelagamy/GHyamah-Test

Verified working

Live deployments (checked 17:23 UTC):

Q1 /health → 200, uptime_s: 1950; / and /metrics valid; requests_total: 118
Q5 /index.html → 200; /data/metrics.json → 31 records, exactly one per minute, no gaps, ssl_days_left: 50

Q1 monitor dashboard (18:02 UTC): 135 checks, 100.0% uptime, avg 900 ms, requests_total: 264 — all against the live deployment.

Images: both build clean and pass their HEALTHCHECKs; pushed to Docker Hub under agamy74.

CLI facts established by direct inspection of binary 0.0.24:

gy version (not gy --version); gy resource app (not gy resource application)
gy auth login accepts --email / --password; no API-token flag exists
gy resource app update <APP_ID> accepts JSON or dot notation via --set, but the field that sets an external image URL is undocumented

Remaining work

1. Add the Docker Hub token — only you can do this

The first workflow run failed after 13 s at the Docker Hub login step: DOCKERHUB_USERNAME is configured, DOCKERHUB_TOKEN is not.

Add it at https://github.com/yassinelagamy/GHyamah-Test/settings/secrets/actions → New repository secret → name exactly DOCKERHUB_TOKEN, value = a Docker Hub access token (hub.docker.com → avatar → Account settings → Personal access tokens → Generate, Read & Write).

Do this before the next push, so the run goes green instead of failing again.

2. Run the pipeline and capture the approval gate

The staging deploy step now carries continue-on-error: true, so the promotion path stays intact: build-push → deploy-staging (adapter exits 78, step marked unsuccessful, job continues) → deploy-production pauses for a required reviewer. That pause is the Q3 evidence.

Actions tab → "Build and deploy" → Run workflow → wait for the Review deployments prompt → screenshot it → approve.

The production step will then also exit 78 and the run finishes red. That is deliberate and defensible: the image was built and pushed, and nothing claims a deployment that did not occur. scripts/ghaymah_deploy.sh writes the exact image handoff to the job summary.

3. Resolve the five remaining VERIFY markers

Public documentation does not contain these answers — I checked /docs, /cli, /products and /changelog. They require the authenticated dashboard.

File	What to look up	Where
`q2-postmortem/POSTMORTEM.md:133`	per-container memory/CPU metrics, restart counts, alert rules, notification channels	the deployed app's detail page
`q3-cicd/CICD.md:116`	is there API-token auth? what field does `gy resource app update` accept for an external image?	account settings / support
`q3-cicd/CICD.md:130`	same as above	—
`q4-scalability/SCALABILITY.md:108`	Block Storage snapshots: retention, encryption, restore	Volumes tab
`q4-scalability/SCALABILITY.md:112`	volume resize, classes, IOPS/throughput, attachment limits, access modes, zone binding	Volumes tab

Rule: if the platform confirms it, state it and delete the marker. If the platform does not expose it, rewrite the sentence to describe the general requirement and note that platform-specific limits were not documented at the time of writing — then delete the marker. No VERIFY string may survive in the submitted repository.

The Integrations tab is also worth a look: if Ghaymah offers a GitHub integration that deploys on push, that is a legitimate CI/CD answer for Q3 even without CLI automation.

4. Screenshots

Save under docs/screenshots/:

q1-service-running.png — the Ghaymah app detail page for ghaymah-api
q1-health-response.png — the live /health JSON
q1-monitor-dashboard.png — the Q1 dashboard with its populated latency chart
q3-approval-gate.png — the Review deployments prompt from step 2
q5-live-dashboard.png — the live Q5 dashboard once it has several hours of history
ghaymah-monitoring.png — optional, supports the Q2 detection section
ghaymah-volumes.png — optional, supports the Q4 storage section

Then link them from the root README.

5. Housekeeping

Decide whether PLAN.md, PROMPTS.md and CHECKLIST.md ship. They document the internal agent workflow; graders do not need them.
Repository variables point at ghaymah-api-staging and ghaymah-api-production, but the deployed application is named ghaymah-api. Either create those two applications or note in CICD.md that they are illustrative targets.
Let both monitors run as long as possible before submitting. Q5's 24 h uptime tile only becomes meaningful after a full day.

Final gate

Must print nothing:

Select-String -Path (Get-ChildItem -Recurse -Include *.md,*.yml,*.sh -File | Where-Object FullName -notmatch '\\\.git\\') -Pattern 'VERIFY|MY_DOCKERHUB_USER|the public URL Ghaymah assigns'

Then verify one last time that both live URLs respond, commit, and push.

5.4 KiB خام اللوم التاريخ