Terraform output fails in workflow shell steps: Backend init required?

[mtb-xt]

In the version of refarch we're using, we're hitting this issue when workflows try to run terraform output and do something with it:

│ Error: Backend initialization required: please run "terraform init"
│ 
│ Reason: Backend configuration block has changed

For example, in this workflow:

  deploy/vpn:
    description: Establish the AWS Client VPN in the core-network account.
    steps:
      - command: terraform deploy ec2-client-vpn -s core-euc1-network
      - type: shell
        command: cd components/terraform/ec2-client-vpn && terraform output client_configuration | sed '1d;$d;$d' > ../../../rootfs/etc/aws-config/flx-core.ovpn

The terraform deploy step works fine, but the direct call to terraform output explodes with the backend error.

Interestingly, running atmos terraform output ec2-client-vpn -s core-euc1-network directly does work, so this seems limited to shell-level usage inside workflows.

Here’s another example:

  output/dns-name-servers:
    description: Output NS records for each dns-primary
    steps:
      - type: shell
        command: |
          cd components/terraform/dns-primary
          function output-dns(){
            terraform workspace select $1 > /dev/null
            terraform output -json zones
          }
          for s in core-gbl-dns platform-gbl-{sandbox}; do
            output-dns $s
          done | jq 'to_entries[] | { (.key): .value.name_servers }'

Same issue here — it tries to access terraform output and chokes, asking you manually run terraform init first.

Are we using some undead or legacy configuration that’s haunting us? 🧟‍♂️
Or maybe missing something in how state/backend init is handled inside the workflow shell steps?

[milldr]

The intention behind both of these workflows is to add a bit of automation around a click ops operation.

For example, with the VPN, we need to get the client configuration from the ec2-client-vpn output and store it locally. Typically we do this by locally running atmos terraform output and manually copy and pasting the client configuration to a shared location for the AWS VPN Client app. The Atmos workflow is supposed to make this easier, but ultimately if it's more effort than value, then I'd recommend running atmos terraform output and copying the output manually.

Similarly, when we're initially setting up DNS, we need to update the domain registrar with the NS records of the hosted zones created by the dns-primary components. Again, you can grab this from atmos terraform output or try the workflow to save a few minutes.

I recommend manually running atmos terraform output for these 2 workflows for now, and we'll look into fixing that bit of scripting in the meanwhile.

[milldr]

Another recommendation from the team is to try cleaning the component first and then rerunning the workflow:

atmos terraform clean ec2-client-vpn -s core-euc1-network
atmos workflow deploy/vpn -f network

[GabisCampana]

Hi @mtb-xt

Thanks for the discussion.

At this point, a clear recommendation has been provided and there hasn’t been additional activity on this thread for some time. Unless there are new constraints or unresolved concerns to raise, I believe this topic can be considered addressed and the discussion can be closed.

Appreciate everyone who contributed context and guidance.