AB2D-7245 tofu logging#1772
Conversation
mianava
left a comment
There was a problem hiding this comment.
I'm not understanding the motivation or rationale for this. Cloudtrail currently has the history of API calls to AWS. What is the use case for having additional tofu logs when we already have them?
The tofu logs capture what CloudTrail can't — the plan output, error messages, and full command context. CloudTrail tells you what AWS executed, but not what tofu intended or why something failed mid-run right?. CloudWatch also gives team a queryable, long-term audit trail . |
We learned from Burling/Mitch that BFD follows this approach: https://cmsgov.slack.com/archives/C011ECLP2NN/p1776956376259769?thread_ts=1776943674.661789&cid=C011ECLP2NN |
@mianava : Please take another look at the comments |
🎫 Ticket
https://jira.cms.gov/browse/AB2D-7245
🛠 Changes
Adds a logging group, a tofu wrapper, and a reusable action that sets up the wrapper. The setup action creates a symlink which intercepts "tofu" commands and reroutes them to the wrapper script, which sets up and sends the logs, while passing the original command to tofu.
Logs are sent to cloudwatch and bundled into streams organized by date, environment, module, and runID.
ℹ️ Context
These changes introduce persistent logging for tofu commands, which alter the aws infrastructure. The wrapper is a minimal script which copies the output of tofu commands and sends them to CloudWatch to be stored and easily accessed. This also provides a more organized location for logs beyond the Github Actions history.
🧪 Validation
Running tofu commands both locally and as part of deploy workflows sends logs to cloudwatch as expected. I ran the deploy workflow for api/worker without error, and the tofu logs appeared in cloudwatch under the correct group/stream. You can check the log group for tofu executions to find examples of logs sent.