Closed lakkeger closed 1 week ago
Interesting, thanks for comparing both the extension and the CLI directly.
I'm surprised there's different behavior as that CLI command is directly used to apply a Template from the extension.
Hi @joshspicer, Thanks for looking into it. Just checking in and wondering if is there any update on this issue or can we apply a work around somehow to the extension?
Apologies for the delay. I've tested with several order builds of the extension (as well as the latest pre-release) and the odd behavior repros.
While I work on a fix, I'd suggest manually applying the Template in the meantime (command scaffolded out below, replace with your own options as needed, set your --workspace-folder
, and omit --tmp-dir
). The dev container CLI can be easily installed from npm with npm install -g @devcontainers/cli
As hinted at in this issue, the CLI is erroneously being passed the wrong template-args
. Below is the verbatim command being invoked after selecting options (I also just clicked through to the defaults).
[2024-09-03T21:59:01.336Z] Running Dev Containers CLI:
templates apply \
--workspace-folder /var/folders/mg/d225vy_56bn0p10vb8z8c1l40000gn/T/tmp-output-dir-1725400741335 \
--template-id ghcr.io/localstack/devcontainer-template/localstack-dood \
--template-args {"imageVariant":"jammy","logLevel":"info","networkName":"info","networkCidr":"info","ipAddress":"info","host":"localhost.localstack.cloud:4566","version":"latest","loadPods":"latest","volumePath":"latest","defaultRegion":"us-east-1","awslocal":"false","cdklocal":"false","pulumilocal":"false","samlocal":"false","tflocal":"false","debug":"false","persistence":"false","usePro":"false","enforceIam":"false"} \
--features [] \
--tmp-dir /var/folders/mg/d225vy_56bn0p10vb8z8c1l40000gn/T/tmp-dir-1725400741335 \
--log-level trace \
--omit-paths []
I think i've found the issue. The bug was related to various options not providing either a proposals
or enum
option. I have fixed that in our extension (treating the provided default
value as the sole option in those cases (which also seems like better UX compared to the blank quickpick with text dialog).
I'll update here when a pre-release build of the extension is available for testing! The other fix here (if any Template maintainer is reading this) is to always include either a proposals
or enum
object for each option (even if the contents of those objects is the same as default
!) That's what was intended when I wrote the spec for it, but here we are now :)
@joshspicer Wow, great find 💯 🥇 Thanks for the detailed feedback and the provided workaround. We make the necessary steps on our end too to remediate the issue in case someone uses an older extension for some odd reason.
Pre-release 0.385.0 of the extension will be available shortly with the fix. Please let me know if it helps!
Steps to Reproduce:
End result:
Docker compose file has wrong values substituted ie:
networkName
haslogLevel
value,volumePath
getsversion
value,This is not an issue if the user uses the same template via the devcontainers-cli with the default or any other inputs:
For comparison find the extension generated docker-compose file:
And the CLI generated:
Similar issue happens with mount values with our "LocalStack Docker-in-Docker" template which works perfectly from the CLI.
Extension generated, see 2nd from the
mounts
:And the cli generated:
All the above results in build errors for obvious reasons.
Does this issue occur when you try this locally?: Yes Does this issue occur when you try this locally and all extensions are disabled?: Yes