Setting up the pipeline in Berlin for the admin_ui config changes. The GitHub Actions workflow runs terraform plan on the pull request, but the step exits with code 0 and logs saying “No changes. Infrastructure is up-to-date.” When I run the exact same commands locally against the same workspace, the plan shows the expected additions for the new queue rules.
Here’s the relevant action step:
- name: Terraform Plan
run: |
terraform init
terraform plan -var-file="prod.tfvars" -out=tfplan
terraform show -no-color tfplan
The workspace is set correctly in the env vars. Local runs use the same state backend URL. Is there a caching issue with the state file in the runner environment, or am I missing a lock configuration that’s causing the remote state to be stale during the PR check?
Sounds like a state drift issue or environment variable mismatch. The local run probably has different backend config or auth context than the GitHub Actions runner. Check your .tfstate lock file permissions in S3/GCS. If the runner can’t read the current state, it might default to an empty state, showing “No changes” because it thinks everything is new, or vice versa if it’s comparing against a stale cached state.
Also, verify the TF_VAR_* exports in the workflow. Sometimes secrets aren’t injected correctly in PR runs due to security restrictions, causing resources to be skipped silently.
Try adding this to debug the state backend connection:
- name: Terraform Init Debug
run: |
terraform init -backend-config="access_key=${{ secrets.AWS_ACCESS_KEY_ID }}"
terraform state list
If state list is empty in CI but populated locally, you’re looking at a backend config mismatch. Check the workspace name in your provider block. It’s easy to miss a dynamic workspace selection in CI that defaults to “default” while you’re working in a named workspace locally.