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
-
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