fix(GRO-1576): add provenance: false to all build-push-action steps (#64)
Disables OCI attestation manifest generation that was hitting a Gitea registry bug when image layers are pre-existing.
Reviewed-by: Lint Roller (QA)
Approved-by: The Dogfather (CTO)
Docker Buildx v6 defaults to OCI attestation manifests (--attest
type=provenance,mode=max). These hit a Gitea registry bug when image
layers are pre-existing (blob mount), causing "unknown" errors on manifest
list push. API image succeeds because it pushes new layers; migrate/seed/
reset fail because their layers already exist.
Disabling provenance attestation on all four build-push-action steps
resolves the push failures. Addresses GRO-1575.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The /api/health endpoint returns 401 on UAT because authMiddleware
was not skipping it — the health check was registered on the Hono app
instance (not the api sub-router), placing it below authMiddleware on
the base app. The fix adds /api/health to the auth skip list alongside
/api/auth/.
The /health endpoint (registered at app level, above all middleware)
correctly returns 200. The /api/health endpoint must also be public
since the task requires confirming it returns 200.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The previous GRO-1544 PR changed /health to /api/health but removed
the /health endpoint entirely. This breaks:
- Dockerfile HEALTHCHECK (curl -f http://localhost:3000/health)
- K8s readinessProbe/livenessProbe (httpGet: path: /health, port: 3000)
Both paths are registered before auth middleware so both remain
publicly accessible without authentication.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
fix(GRO-1533): fix migration 0031 for empty databases (#57)
Adds ADD COLUMN IF NOT EXISTS for coat_type and pet_size_category before ALTER TYPE casts, making migration safe for both fresh and existing databases.
Reviewed-by: gb_lint (QA)
Approved-by: CTO
Migration 0031 tries to ALTER the coat_type and pet_size_category columns
on the pets table to use new enum types, but no prior migration adds
these columns. On a fresh DB (after the reset CronJob wiped all tables),
this causes the entire migration chain to fail and roll back.
Added ADD COLUMN IF NOT EXISTS before the ALTER TYPE so the migration
works both on fresh databases and existing ones with the columns.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The migration journal references 0032_staff_read_at but the SQL file
was never committed. drizzle-kit migrate fails with "No file
./migrations/0032_staff_read_at.sql found" which blocks all subsequent
migrations including the 0033 default_buffer_minutes fix.
Added as a no-op since the staff table schema has no readAt column.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Added TC-API-0.1 for GET /api/health (unauthenticated).
Corrected path from /health to /api/health (GRO-1544).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The health check was registered on `app` at `/health`, but the HTTPRoute
routes `/api/*` to the API pod. Since auth middleware protects the /api
basePath, GET /api/health fell through to authMiddleware → 401.
Now registered on `api` before auth middleware at /api/health.
Updated UAT_PLAYBOOK.md §GRO-1485 — new health endpoint path.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Lines 108-109 were duplicates of lines 102-103 from the PR #12 merge.
Removing the duplicate pair resolves the TS1117 error on dev.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
@@ -21,6 +21,14 @@ GroomBook API is a Hono-based REST service (TypeScript/Node.js) powering the pet
## Test Cases
### 4.0 Health Check
| # | Scenario | Steps | Expected |
|---|----------|-------|----------|
| TC-API-0.1 | Unauthenticated health check | GET /api/health | 200 OK, `{"status":"ok"}` |
> **Note (GRO-1544):** Health endpoint registered on `api` basePath before auth middleware at `/api/health`. The old path `/health` was incorrect (routed to web pod via HTTPRoute `/*` rule).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.