Fix for FRB2797-Flexible Post Apply execution even if Apply Fails#38194
Fix for FRB2797-Flexible Post Apply execution even if Apply Fails#38194anupama-vijay wants to merge 1 commit intohashicorp:mainfrom
Conversation
|
Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement Learn more about why HashiCorp requires a CLA and what the CLA includes Anupama Vijay seems not to be a GitHub user. Have you signed the CLA already but the status is still pending? Recheck it. |
Changelog WarningCurrently this PR would target a v1.15 release. Please add a changelog entry for in the .changes/v1.15 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label. |
|
Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement Learn more about why HashiCorp requires a CLA and what the CLA includes Anupama Vijay seems not to be a GitHub user. Have you signed the CLA already but the status is still pending? Recheck it. |
BugFix
bug-fix FRB2797 -Terraform - Flexible Post Apply execution even if Apply Fails
https://hashicorp.atlassian.net/browse/FRB-2797
Post-apply run tasks are now triggered even when an apply fails, so configured post-apply automation still runs before the run transitions to its terminal errored state.
Description
Fixes a gap where workspace post-apply run tasks were skipped whenever terraform apply errored.
When an apply fails, the agent previously reported the run as errored immediately, This change makes changes in function opApply.
The function starts by defining postApplyStage := tfe.Stage("post_apply") because the go-tfe client doesn’t expose a constant for that stage. This lets the code still detect and wait for post-apply task stages if the server reports them. When apply failed applies: if the apply object exists, it refreshes it (Applies.Read) and checks whether the apply status is "errored". If so, it refreshes task stages again to discover the dynamically relevant post-apply stage ("post_apply"), waits for that stage if present, and then re-reads the run so callers observe the final post-task status
Result: post-apply tasks execute even on apply failure, and the run then ends in the expected errored terminal state after post-apply completes.
Rollback Plan
CHANGELOG entry
Related PR
PR
Related Link
Jira
Example Output