Repository navigation
fix(override): make approved overrides unblock app repos and split FAILED from HIGH - #182
Conversation
…ILED from HIGH approve-override.yml re-ran the blocked run with the platform repo's github.token, which cannot touch app repos, so an approved override never restarted an app's apply. The repo and run now come from the plan key (validated before signing); platform runs are still re-run automatically and app runs get the exact "Re-run failed jobs" step in the job summary and Slack. invoke-plan-review.sh retries reviews the service could not complete, and the logs, PR comment, Slack alert and blocked Terraform Apply say whether the review service failed or the review found HIGH risk, with how to request an override. docs/apply-gate.md documents the request path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Terraform Plan🚧 Changes detected — Plan: 0 to add, 1 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟢 LOW Plan updates one existing Lambda function (javabin-plan-review) in place with a new source code hash; no resources are created or destroyed.
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Merged origin/main (#184, #178, #180, #187, #186, #185) into this branch with a merge commit. Conflicts:
Checks after the merge: scripts/tests 196 OK, lambda-src/tests 252 OK, Not changed: some docs still say "board member" for override approval (ci-workflow.md:48, reusable-workflows.md:216, README.md:16, apply-gate.md:202, approve-override.yml:4), but this PR's new text says "platform team". That was already the case before the merge. |
Terraform Plan🚧 Changes detected — Plan: 3 to add, 12 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🔴 HIGH Plan adds 3 resources and updates 12 in place with 0 destroys; the main concern is that CI OIDC trust policies for three IAM roles are widened to accept subjects from a different GitHub repository path (javaBin@95047/...), and the production deploy role's ECS permissions are expanded.
|
# Conflicts: # docs/reusable-workflows.md
Terraform Plan🚧 Changes detected — Plan: 6 to add, 12 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🔴 HIGH Plan adds 6 resources (EventBridge rules, targets, Lambda permissions) and updates 12 IAM/Lambda resources with 0 destroys; the IAM changes widen CI trust policies and team-provisioner permissions, including a new permissions-boundary-setting grant, so it needs careful review before apply.
|
Problem
approve-override.ymlrangh run rerun "$RUN_ID" --repo "$REPO" --failedwith the platform repo'sgithub.token. That token only covers javaBin/platform, so for an app repo the override got signed but the blocked apply never restarted. All past override runs targeted javaBin/platform, so the app path had never run. No GitHub App installed in the org hasactions: writeand is usable here (thejavabin-platformApp has administration/contents/members only), so a cross-repo re-run token can't be had without granting an App more access.Change
scripts/override-target.sh: the repo and run now come from the plan key (plans/<org>/<repo>/<run_id>/tfplan) and are checked before anything is signed.repoandrun_idare now optional inputs that must match the key if given. For javaBin/platform runs the failed jobs are still re-run automatically. For app repos the job summary, a notice annotation and the Slack message give the run URL and say to click Re-run failed jobs. The apply gate checks foroverride.jsonon every run, so that re-run is all it takes. The security properties stay the same: signing still needs theoverride-approvalenvironment and the gate's OIDC workflow check.scripts/invoke-plan-review.sh: retries reviews the service couldn't complete (invoke error, Lambda timeout/errorMessage, FAILED verdict), up toREVIEW_INVOKE_ATTEMPTS(default 3) with backoff. Refusals (bad OIDC token, another repo's plan) are not retried. It printsPlan review service failed … not a risk findingorPlan review found HIGH risk. Both still block the apply.retrying, and doesn't post FAILED to Slack while the caller will retry (HIGH always posts). The Slack text and PR markdown now say whether the service failed or the review found HIGH risk, and the alert links the blocked run.scripts/override-help.sh(called frominvoke-apply-gate.shwhen the apply is blocked): prints and writes to the job summary what to do.gh workflow run approve-override.yml …command; then Re-run failed jobs.docs/apply-gate.md. Updated override flow,reusable-workflows.md,ci-workflow.md,lambda-functions.mdandCLAUDE.md.javabin.ymlis unchanged.Verification
python3 -m unittest discover -s scripts/tests: 145 OK. Newtest_override_flow.pyruns the shell scripts with fakeaws/curl/gh: retries until a verdict,retryingonly on non-final attempts, FAILED vs HIGH wording, no retry on refusals, plan-key parsing and mismatch refusal, platform re-run vs app instructions.python3 -m unittest discover -s terraform/lambda-src/tests: 222 OK, including new plan-review notification tests.shellcheck -s shon the new and changed scripts (only a pre-existing SC2129 style note in invoke-apply-gate.sh), andactionlinton approve-override.yml.Notes
retrying, so an outage can post up to 3 FAILED alerts per run.override.jsonsigned for an earlier attempt is still accepted for the new plan. Binding the HMAC to the review (for example a review ID inrisk.json) would close it.actions: writeand mint a token in approve-override. That is an org admin decision.🤖 Generated with Claude Code