[EPAC-2101]: re-add terraform apply for staging workspace to backend staging deploy#627
Merged
riddim-developer-bot[bot] merged 1 commit intoMay 26, 2026
Conversation
riddim-developer-bot
Bot
added
the
autonomous
riddim-developer-bot
Bot
deleted the
symphony/epac-2101-re-add-terraform-apply-for-staging-workspace-to
branch
May 26, 2026 01:48
riddim-developer-bot Bot
added a commit
that referenced
this pull request
May 26, 2026
…le management (#628) ## Summary - Add `lambda:ListVersionsByFunction`, `lambda:CreateFunction`, `lambda:DeleteFunction`, `lambda:GetPolicy`, `lambda:ListTags`, `lambda:TagResource`, and `lambda:UntagResource` to both the staging and production CI IAM role policies - These permissions are required by the Terraform AWS provider to refresh Lambda function state, create new functions from the deployment manifest, manage tags, and handle full lifecycle operations ## Root cause PR #627 (EPAC-2101) re-added `terraform apply` for the staging workspace to the backend staging deploy workflow. The Terraform provider calls `lambda:ListVersionsByFunction` during the state refresh phase, but the `ManageStagingLambda` IAM policy only included the subset of Lambda actions needed for direct CLI deploys (update-function-code, get-function, etc.) — not the broader set Terraform needs. Failed run: https://github.com/RiddimSoftware/epac/actions/runs/26427674950 Error: `User: arn:aws:sts::227530433709:assumed-role/GitHubActions-epac-backend-staging/GitHubActions is not authorized to perform: lambda:ListVersionsByFunction on resource: arn:aws:lambda:us-east-1:227530433709:function:epac-health-staging` ## Post-merge action required The IAM policy is managed by the **core** Terraform workspace (`infra/terraform/core/`), which is applied separately from the staging workspace. After this PR merges, the core workspace must be applied before the next staging deploy will succeed: ```bash cd infra/terraform/core terraform init terraform apply ``` ## Verification - `terraform validate` passes for the core workspace - Production policy updated with the same permissions for consistency Reviewer-Boundary: review-only Resolves EPAC-2102 _Issue estimate was not set in Linear._ Co-authored-by: riddim-developer-bot <developer-bot@riddimsoftware.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
terraform applystep for the staging workspace was removed in EPAC-2072 (PR #602) because the CI IAM role lacked S3 access to the Terraform state bucket. That IAM gap has since been fixed. Withoutterraform apply, newly registered Lambda services (e.g.epac-hansard-search-index-stagingfrom EPAC-2062) never get provisioned — the deploy job skips them and downstream workflows likehansard-search-reindex.ymlfail withResourceNotFoundException.What changed
infra-applyjob tobackend-staging.ymlthat runsterraform initandterraform apply -auto-approveininfra/terraform/staging/using the existingAWS_BACKEND_STAGING_ROLE_ARNcredentials.hashicorp/setup-terraform@v3step so the Terraform CLI is available on the runner.deployjob dependency fromneeds: preparetoneeds: [prepare, infra-apply]so deploys only run after infrastructure is provisioned.infra/terraform/staging/**to thepathstrigger so infra-only changes also trigger the workflow.Trade-offs not taken
-targetflags to scope the apply — full workspace apply is required so all manifest-registered services are provisioned.terraform planas a separate preview step — the existingconcurrencygroup prevents concurrent runs and the staging workspace is a non-production environment where plan review overhead is not warranted.Verification
actionlintpasses clean on the modified workflow file.infra/terraform/staging/) confirmed to exist withmain.tf,variables.tf,outputs.tf,versions.tf.Risks
terraform applyon this workspace — the plan output should be reviewed in the workflow run summary after the first execution. Any unexpecteddestroyactions on existing resources warrant investigation.terraform applyholds the DynamoDB state lock for its duration; the workflow'sconcurrency: group: backend-staging-deployprevents concurrent runs.Resolves EPAC-2101
Reviewer-Boundary: review-only