fix(ci): check out the repo in the lambda deploy job

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code

[nourshoreibah]

Fixes the Lambda Deploy failure on feat(roles): project roles are Admin, Director, Student (#311) (run 31554276329).

What actually happened

The lambdas deployed fine. Deploy lambda was ✓ on all three of projects / expenditures / donors and migrate was ✓ — the roles change is live in production. The job died on the step after the deploy:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/branch/branch/.github/actions/slack-deploy'.
Did you forget to run actions/checkout before running your local action?

The deploy job's Thread step (live) uses the local composite action ./.github/actions/slack-deploy, but the job never ran actions/checkout, so the action wasn't on disk. It is the only job in the repo that used the local action without checking out — prep, migrate, notify, frontend-deploy and all four terraform-apply jobs already do.

Not a regression from #311

Every Lambda Deploy on main that actually shipped a lambda has failed this way since threaded notifications landed (#270):

Run	Commit	Shape
31554276329	#311	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30598505113	#290	Deploy lambda ✓, Thread step (live) ✗, Notify ✓
30423381265	dispatch	✅ green — migrations_only, so deploy was skipped

The only green run in that window is the one where the deploy job never ran. That's the tell.

Why Slack said "complete" while GitHub went red

Separate bug, and the reason there was no failure notification. finalize decided pass/fail purely from the lambda-result-*/*.meta files, and those record steps.deploy.outcome — the aws-cli call, which succeeded. A job that dies after writing its .meta still finalized green. The Slack thread also stopped updating after migrate, because the per-lambda live steps are posted by the step that couldn't load.

So finalize gains a force-failure input, and notify passes it the actual job results.

Changes

• lambda-deploy.yml — actions/checkout@v4 as the first step of deploy. First, not last: checkout cleans the workspace and would wipe the downloaded lambda.zip.
• slack-deploy/action.yml — new optional force-failure input (default 'false'), seeding anyFail in finalize mode.
• lambda-deploy.yml — notify passes force-failure: ${{ needs.migrate.result == 'failure' || needs.deploy.result == 'failure' }}.

Verification

• actionlint (via Docker) — no findings on either changed file. The one repo-wide non-shellcheck finding is pre-existing, in regenerate-db-types.yaml.
• Both files parse as YAML; the embedded github-script body passes node --check.
• deploy step order confirmed: checkout → compute name → download artifact → creds → deploy.
• Finalize decision table exercised against real .meta files:

.meta contents	force-failure	result
all success (the shape of run 31554276329)	true	FAIL ✅
all success	false	COMPLETE ✅
donors|failure	false	FAIL ✅
donors|failure	true	FAIL ✅

Note for the reviewer

Merging this won't exercise the fix — Lambda Deploy's paths filter is apps/backend/lambdas/**, shared/types/**, apps/backend/db/migrations/**, and this PR only touches .github/**. It gets validated on the next lambda merge, or by running the workflow manually with migrations_only: false.

terraform-apply's notify has the same latent .meta-only blind spot, but it isn't broken today (all its jobs check out), so I left it alone.

🤖 Generated with Claude Code