A nightly job runs terraform plan for many workspaces and should open a ticket only when a workspace has pending changes, while treating errors separately. Which approach lets the script tell these outcomes apart reliably?
Select an answer to reveal the explanation.
Short Explanation
You want the plan to answer with a number, not a paragraph. -detailed-exitcode gives you 0 for nothing to do, 1 for trouble, and 2 for changes waiting. The trap is grepping the human output, which can change wording between releases.
Full Explanation
By default terraform plan exits with 0 on success whether or not changes were found, and 1 on error. The -detailed-exitcode option makes the exit status more granular: 0 means the plan succeeded with an empty diff, 1 means an error occurred, and 2 means the plan succeeded and contains changes. A script can branch on that code to open tickets only for 2 and route 1 to error handling, without parsing text. The human-readable output is intended for people and can change between releases, so matching phrases such as No changes is brittle and also lumps errors in with pending changes. A refresh-only plan answers a different question, whether remote objects differ from state, and does not report configuration changes; reading a plain zero exit as pending changes also inverts the meaning. The size of a saved plan file is not a defined signal, because plan files carry configuration and state snapshots regardless of whether actions are planned. Exam caveat: for richer detail, convert the saved plan with terraform show -json and inspect each resource change's actions. Operational check: run the job against a workspace known to be clean and one with a pending change, and confirm the script receives 0 and 2 respectively before scheduling it.