Deployment

Product and architecture decisions

• This repo is Mini Kanban, not the course’s interview/canvas demo. Stack: React + Vite, FastAPI, OpenAPI as the contract, no auth in v1, JSON camelCase.
• One production image: Node builds the UI, Python serves API + static files from the same origin (VITE_API_URL=""). Local dev stays split (5173 / 8091).
• Persistence: started in-memory (AGENTS.md). Spec said SQLite. Homework asked for Postgres. We used SQLAlchemy that accepts SDIP_DATABASE_URL or DATABASE_URL, rewrites postgresql:// to postgresql+psycopg://, and still falls back to SQLite.
• Compose: Postgres 16 + app, healthcheck, volume. Ports 8091 / 5432.
• “Two sessions” for this app: two browser contexts sharing one DB, plus a /?board=<id> join link. There is no interviewer, candidate, or canvas.
• AWS: CloudFormation (public subnets, no NAT, RDS, ALB, Fargate, ECR). Local deploy with a temp admin user; GitHub deploy with OIDC, not access keys.
• CI: frontend and backend tests in parallel, then Compose + integration + Playwright, then deploy if AWS_ROLE_ARN is set. Success = GET /health → {"status":"ok"}.

Misunderstandings

Homework copy vs this repo. Prompts talked about localhost:8000, interview sessions, join links, and a canvas. The first two-session check looked for that app, found nothing on port 8000, and stopped. Later we mapped the same idea onto Kanban (two tabs / Playwright contexts). Spec also listed sharing as out of scope; we added a join URL anyway so that homework step could exist.

SQLite vs Postgres vs in-memory. Three sources of truth. We kept a dual backend instead of picking one.

.yaml vs .yml, and where tests live. Homework first asked for docker-compose.yaml and tests under the backend. The later checklist wanted docker-compose.yml and repo-root tests/integration/. We renamed and moved files to match the checklist.

“Wired” vs “working.” Workflows already called OIDC and polled /health, so those boxes looked done. In AWS the running image was older: /boards 200, /health 404, ALB still checking /boards. That is not a successful health validation.

OIDC vs the temp IAM user. The temp user (or root) is only for creating stacks and setting GitHub up. GitHub Actions should assume mini-kanban-github-actions. Deleting the user afterward is so long-lived keys are not left around; OIDC does not use them.

Node 20 vs the real deploy error. The Actions log warns that Node 20 is deprecated (configure-aws-credentials@v4). That is not why the job failed. The failure is: role-to-assume was a role name, not a full ARN.

Repo variables vs the production environment. Deploy uses environment: production. A variable set only at repo level (or as a secret, or as the short role name) can still fail the AWS action.

“Health is the only CI/CD problem.” That was incomplete. Live /health was missing and GitHub OIDC was not actually succeeding. The next run failed on AWS_ROLE_ARN before it could even hit /health.

Errors and operational misses

• Docker Desktop was down more than once, so images were not rebuilt and AWS stayed on the old /boards image.
• make was not on PATH; gh was not installed, so the agent could not set AWS_ROLE_ARN.
• AWS CLI first had no credentials; later a principal in account 577331852018 created the stacks (OIDC + app).
• Playwright needed getByRole('textbox', { name: 'Board name', exact: true }) because “New board name” also matches “Board name”.
• AWS_ROLE_ARN almost certainly got the role name mini-kanban-github-actions instead ofarn:aws:iam::577331852018:role/mini-kanban-github-actions.
• Workflows used Node-20 actions (checkout@v4, configure-aws-credentials@v4). The ARN bug is the blocker; the Node warning is noise unless you pin newer action majors.

What is true now

Correct GitHub variable value:

arn:aws:iam::577331852018:role/mini-kanban-github-actions

Set it on the repo and on the production environment if that environment exists. Then commit/push the workflow fix and re-run Deploy so the live image actually gets /health.