:question: I have atmos creating two different wo...
# atmos
z
❓ I have atmos creating two different workdirs for the same component using JIT 🧡
if I do a
Copy code
atmos terraform source pull --force -s demo demo-cluster-codepipeline-iac
atmos terraform plan -s demo demo-cluster-codepipeline-iac
it produces
Copy code
tree -L 2 .workdir 

.workdir
└── terraform
    β”œβ”€β”€ demo-dev-demo-cluster-codepipeline
    └── demo-dev-demo-cluster-codepipeline-iac

4 directories, 0 files
Not sure if this really matters tbh. just an odd thing I noticed
I'm guessing that the
atmos terraform source pull
doesn't respect the
metadata.component
parameter when naming directories
a
@Zack we have merged this PR https://github.com/cloudposse/atmos/pull/2093 with a fix for how Atmos generates the workdir paths (will be released today). Not 100% sure if it will resolve the issue you reported - if not, please open another issue and will fix it ASAP
πŸ‘€ 1
z
πŸ€” not sure if it will fix the JIT thing. let me checkout that branch and test
e
> aknysh > closed this as completedin #2093 15 hours ago
not yet released
z
@Erik Osterman (Cloud Posse) I tried this using
--use-version=2093
I think it's something more specific to JIT ignoring the metadata.component when adding to the .workdir
specifically when doing an
atmos terraform source pull
e
The issue above was that we were not using the instance name when provisioning the working directory.
So that meant that two instances would share the same component folder, which was an oversight.
Now, with the PR above, 2093, that should no longer be the case.
z
Try out my Steps to Reproduce 😁
e
πŸ˜ƒ
z
I made a whole schema for it for claude to spit out for issues for you guys lol
❀️ 1
e
We just released some claude skills this morning in Maine, and I think it would be slick if we could upstream whatever you're doing to create those reproduce cases. It's amazing.
z
I stole the idea from the kustomize repo's examples
unfortunately I only have claude pro so I can't go too crazy with skills
this is all I do. I just feed it some extra context of what my problem is and tell it to fill out an issue with given headers
e
From claude: It IS the same underlying issue - using base component name instead of instance name for the workdir path. PR #2093 fixed it in the workdir provisioner (
pkg/provisioner/workdir/workdir.go
), but missed the source provisioner(
pkg/provisioner/source/provision_hook.go
). The key: when both source AND workdir are enabled, the workdir provisioner skips entirely and defers to the source provisioner: `pkg/provisioner/workdir/workdir.go:107-109`:
Copy code
if hasSource(componentConfig) {
    // Source provisioning will handle creating and populating the workdir.
    return nil
}
So the PR #2093 fix at line 115 (
atmos_component
check) never runs for JIT-vendored components - the source provisioner handles the workdir creation instead, and it still uses
extractComponentName()
(base component name). It’s the same fix needed, just in the source provisioner path that was overlooked
πŸ™Œ 1
@Zack can you try this out tomorrow? https://github.com/cloudposse/atmos/pull/2137
--use-version=2137
z
confirmed
( understood that this is already in main ) lol