Replies: 1 comment 2 replies
-
Thanks for opening. I'm curious to get @chrmarti's thoughts on this one. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Using: Dev Containers 0.369.0 in VS Code 1.90.1 (611f9bfce64f25108829dd295f54a6894e87339d)
macOS v14.5 on M1 Pro, running linux/amd64 Ubuntu 24.04 LTS devcontainer/remote-ssh via Docker Desktop/Engine v26.1.4
In a typical devcontainer build, my log has 11 x "Exit Code 1" log messages and 1 x "Exit Code 127" log message. I can summarise the log messages as all effectively being "false-positives" and honestly, confusing for any user and why I'm spending time to write this discussion topic. IMO, these log messages unless critical/causing a break, should be silenced.
The vast majority of the "Exit Code 1" log messages are from various
test -d
ortest -f
checks and presumably, if not present (Exit Code 1
), then the devcontainer build creates the dir/file. End users don't need to see this, unless it fails.Similarly, if
gpg
is not installed/present in the devcontainer, you will get aExit Code 2
log message. Again, should only be surfaced if it needs fixing/breaks some functionality.Ideally? I propose all "Exit Code" log messages are removed and only surfaced if there is actually an error that the end-user needs to know about. Additionally, I note that I applied the
"dev.containers.logLevel": "info"
at both VSC user-settings level on the macOS host as well as in mydevcontainer.json
and that had no effect compared to setting it to:"dev.containers.logLevel": "debug"
, so I question the lack of granular log verbosity in the devcontainer build logs here as well...Examples:
and some more:
and
Exit Code 2
example:and a few more, marker errors:
Beta Was this translation helpful? Give feedback.
All reactions