Deploy workflow for the storage-allocation worker Lambda
This story has no user-facing surface — there is nothing to click through.
It adds the missing CI/CD deploy workflow that packages and ships the
pramaan-storage-allocation Lambda (the worker code shipped by
Story-2541). Without it, pramaan-storage-allocation-staging —
the execution role Chore-2549's Terraform already targets — never exists,
and that infra PR's staging apply fails.
What shipped
A new GitHub Actions workflow,
.github/workflows/deploy-storage-allocation-worker.yml,
mirroring the existing deploy-context-embed-worker.yml
pattern: lint + unit tests, then package/deploy the handler to a
staging Lambda inside the VPC, with an idempotent execution-role
bootstrap and a cheap post-deploy smoke invocation.
Ownership split (why this doesn't duplicate Chore-2549)
| Owner | Owns |
|---|---|
| This workflow (pramaan-functions) | The Lambda function + its execution role's trust policy, VPC access, and a Logs/KMS-only inline policy. |
| pramaan-infra (Chore-2549, PR #158) | The EventBridge daily schedule, the Lambda invoke permission, a
separate s3:ListBucket + ce:GetCostAndUsage
inline policy on the same role, and the failure alarm. |
How this gets verified live
Once this PR merges, the workflow deploys the function and the
deploy's own smoke step proves the packaged artifact imports cleanly
in the live VPC. Chore-2549 merges next, wiring the schedule and its
IAM reads onto the now-existing role. The real
{"mode":"daily"} proving invocation — Chore-2549's own
acceptance criterion, showing one
billing.vendor_cost_event(category=storage) row written —
runs as a follow-up step after both land, sequenced outside this
story's scope.