https://cloudposse.com logo
Join Slack
Powered by
Hello, I’m trying to understand the correct way to...
# atmos
s
Hello, I’m trying to understand the correct way to use workdir and source provisioning with the Terraform plan GitHub Action. I’m currently using cloudposse/github-action-atmos-terraform-plan with my components which use workdir + source provisioning enabled, because I want to avoid cache collisions when running multiple stacks in parallel that share the same component. The issue I’m encountering is that the action attempts to write the Terraform plan file to: terraform/components/component/ However, when workdir is enabled, Atmos provisions the component to: .workdir/stack-component/ This causes a mismatch between where the action expects the component to exist and where Atmos actually provisions it. For context: My component base path is terraform/components My current workaround is to pre-create the expected component folder in the pipeline, while still running Terraform from the component workdir. Before continuing with this approach, I wanted to ask: Is there a recommended way to use workdir + source provisioning with the plan action? Or is there a configuration option I might be missing so the action uses the Atmos workdir path instead?
e
We had a bug that was recently fixed in 1.209.
What version are you on?
(the bug was exactly as you described it, using 
.workdir/<stack>-<component>
instead of 
.workdir/<stack>-<component-instance>
s
1.209.0
e
Ugh, that's a bummer!
this was the PR
Let me kick off another investigation.
When 
provision.workdir.enabled: true
+ source provisioning is configured on a component, the GitHub Action 
cloudposse/github-action-atmos-terraform-plan
gets the wrong 
component_info.component_path
from 
atmos describe component
. The action expects the plan file at 
terraform/components/<component>/
but Atmos actually runs terraform from 
.workdir/<stack>-<component>/
, causing a path mismatch.
Aha! I misunderstood the problem you were talking about.
Yes, we haven't tested the workdir with the github actions; note that all that will be moved into Atmos natively starting with 1.210.
m
does thing mean the GHA's will be "abandoned" at some point? or how should I see that? Or you mean the logic now in the GHA will move to the cli?
e
Yes, we will be doing minimal updates to the GitHub actions, with the intention of archiving them once we achieve maturity/stability with Native CI.
There's a night and day difference in DX, with more or less feature parity.
m
I hope you can fix that the warning from TF Cloud also pastes the entire plan output as a comment :D
🙈
never so a "body" too big message before on a github action 😄
e
Can you elaborate?
m
i can make a issue on GH as well for it, but you have the plan output in the comment, with an arrow that you can open and close. then I get the warning messagr from TF Cloud as a comment as well, (for example variables not set) but then the entire plan output is part of the comment block.
I tried to play around with the tfcmt template and make a custom step myself but not sure why it's not working yet.
e
Yes, a few things that we are doing to mitigate that.
First, we predominantly use job summaries instead of PR comments with the plan output. Job summaries have a much higher limit. That way it doesn't pollute the PR.
PR comments are implemented in the core, but might not be in the initial release early next week. But the template itself is fully customizable.
You bring up 
tfcmt
, which is a great reference. What we've done is implement that natively in Atmos using 
gomplate
(as a go module). Thank you. This gives you control over the format.
11 Views
Open in Slack
PreviousNext
Powered by