You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No user features to update
TypeError: t.startsWith is not a function
at ytA (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:465:2285)
at NH (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:464:739)
at async KtA (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:481:3692)
at async AB (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:481:4807)
at async hrA (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:661:13255)
at async lrA (/usr/local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:661:12996)
{"outcome":"error","message":"t.startsWith is not a function","description":"An error occurred setting up the container."}
The issue was reproduced in jenkins (where we have the CLI embedded there) but self resolved after a new pod created that runs the cli, (btw: no devcontainer.json changes happend in between) so i assume it is something related to caches or some files/data stored by the cli ?
The text was updated successfully, but these errors were encountered:
I wonder if there's some kind of caching issue as the CLI might cache certain data for performance reasons. If this cache becomes corrupted or contains unexpected data types, it could lead to errors. A new pod would start with a clean state, which could explain why the issue resolved itself.
Can you update the cli version to v0.65.0 and retry?
the issue somehow always reproduced in some env setup i do not have access anymore so unfortunately i can't reproduice , but i think the Exception stack is enough to see there is something in code that expected a different Type inside it, so i would suggest adding a more strict check here and print to log the actual object to see what is it in case it happens again.
using 0.60 version of the cli i got :
The issue was reproduced in jenkins (where we have the CLI embedded there) but self resolved after a new pod created that runs the cli, (btw: no devcontainer.json changes happend in between) so i assume it is something related to caches or some files/data stored by the cli ?
The text was updated successfully, but these errors were encountered: