Publish the terraform state after apply

[refeed]

The check in chapter 2 reads the plan —
what we intend to do. This adds a second call to the same action, after Apply, carrying the state —
what is actually there.

- name: Read the current state
  run: terraform show -json > state.json

- uses: StackGuardian/tirith-iac-governance-action@v2.1.1
  continue-on-error: true
  with:
    sg-api-key: ${{ secrets.SG_API_TOKEN }}
    sg-org: ${{ vars.SG_ORG }}
    input-path: state.json
    input-kind: terraform_state
    comment: false
    check: false
    comment-tag: post-apply

The state is masked in the runner before it goes anywhere, lands on the workflow as
artifacts/tfstate.json, and updates the platform's view of what this repository actually owns.
state.json is gitignored, so it is never packed into the uploaded source.

Why it reports nothing

Publishing state is not a verdict. This call has no opinion to offer about whether the change is
allowed — chapter 2's gate already
decided that, before the apply, which is the only moment where the answer can still change anything. So
the call reports through neither surface: one comment and one check run on this PR, both belonging
to the gate.

Left to report, it had one: 2 warned, 1 passed, where both warns were the plan rule and the cost rule
declining to evaluate a state document. That is correct behaviour — a rule that could not run does not
get to look like a rule that passed — but as a second comment it reads like half the check failed to
fire. Its verdict is still in the job summary for anyone who wants it.

comment-tag stays even with both surfaces off, which looks contradictory and is not: the tag also
names the uploaded bundle (tirith-bundle-<sha>-post-apply.tar.gz), and the default would overwrite the
one the gate uploaded a minute earlier.

continue-on-error because a publication step must not be able to fail a deploy. The trade is that a
failed publish now goes unnoticed on the PR — visible only as the missing
Published the state document line in the log.

Neither step is conditional. On a pull request the apply is skipped, so this publishes the state as it
stands right now; on a push to main it publishes what was just applied.

This is also the one chapter that only works with credentials: uploading state to the platform is not
something local mode does at all.

---

Chapter 5 of 5. Based on #19 · Last chapter. Start at #16.

[github-actions]

🛡️ Tirith — 1 warned, 3 passed

_{Scanned commit fd3c285 · dir . · workflow github-com-StackGuardian-tirith-action-demo-deploy}

+ aws_s3_bucket.analytics                          create
    + bucket = "demo-tirith-action-analytics-790543352839"
    + force_destroy = false
    + tags = {"Demo":"tirith-action-demo","Name":"tirith-action-demo","Owner":"data-platform"}
    + tags_all = {"Demo":"tirith-action-demo","Name":"tirith-action-demo","Owner":"data-platform"}
    … and 23 computed attribute(s), known after apply

Plan: 1 to add, 0 to change, 0 to destroy. 5 unchanged.

	Policy	Rule	Resource
⚠️	__sg.checkov-best-practices	checkov-best-practices	aws_s3_bucket.analytics, aws_s3_bucket.artifacts
✅	tirith-demo-cost-ceiling	monthly-cost-ceiling	—
✅	tirith-demo-opa-check	s3-naming-and-region	—
✅	tirith-demo-s3-owner-tag	s3-buckets-must-declare-an-owner	—

⚠️ __sg.checkov-best-practices › checkov-best-practices

• Ensure S3 buckets should have event notifications enabled
• Ensure S3 buckets should have event notifications enabled
• Ensure that S3 bucket has a Public Access block
• Ensure the S3 bucket has access logging enabled
• Ensure that S3 buckets are encrypted with KMS by default
• Ensure that S3 bucket has cross-region replication enabled
• Ensure that S3 bucket has cross-region replication enabled
• Ensure all data stored in the S3 bucket have versioning enabled
• Ensure that an S3 bucket has a lifecycle configuration

Resources:

• aws_s3_bucket.analytics
• aws_s3_bucket.artifacts

_{💵 Estimated monthly cost: 1.00 USD (+1.00 from this change)}

_{✅ 3 passed · View run in StackGuardian}