LABEL names can not be blankdockerfile-utils(34) -- note the lack of a spacecannot should be one wordYes, I suspect that you're using someone else's library. I'm wearing an end user hat today, using your extension, and hoping that you'll manage the upstream bug reporting for me. If I have a product and I use a third party component that yields poor output, it reflects poorly on me, and I can choose to get it fixed upstream, fix it downstream, or replace the component. I can't simply say "not my problem", because it reflects on the quality of my product.
Tested: Disabling the Docker 1.11.0 component causes the warning to go away.
Expected results:
LABEL names cannot be blank dockerfile-utils(34)Version: 1.55.1
Commit: 08a217c4d27a02a5bcde898fd7981bda5b49391b
Date: 2021-04-07T18:22:52.186Z (3 days ago)
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Darwin x64 19.6.0
ms-azuretools.vscode-docker 1.11.0
@jsoref Thank you for your bug report. I have opened https://github.com/rcjsuen/dockerfile-utils/issues/95 to track this.
The temporary workaround would be to put a space before the \ escape character.
LABEL "com.github.actions.name"="Spell Checker" \
"com.github.actions.description"="Check repository for spelling errors" \
"com.github.actions.icon"="edit-3" \
"com.github.actions.color"="red" \
"repository"="http://github.com/check-spelling/check-spelling" \
"homepage"="http://github.com/check-spelling/check-spelling/tree/master/README.md" \
"maintainer"="Josh Soref <[email protected]>"
@jsoref This should get fixed with #2866.
I'm glad I filed this issue here, the maze of dependencies from vscode-docker to underlying modules is way too complicated for me 馃檨 .
btw, it isn't readily apparent to me what the (34) means in this message or why there's no space between it and the text that precedes it.
I'm glad I filed this issue here, the maze of dependencies from vscode-docker to underlying modules is way too complicated for me 馃檨 .
That's understandable. I've broken things down to enable clients to pick and choose what they want but I can understand how it is not super obvious where some piece of code is.
btw, it isn't readily apparent to me what the
(34)means in this message or why there's no space between it and the text that precedes it.
I believe that is Visual Studio Code's way of rendering diagnostics messages from language servers so it's not really an issue unique to the Docker extension.
Is the number 34 related to something in the language server implementation? It doesn't appear to be a local line/column number (it's at least stable for my file).
It's hard to file good bugs w/o having some vague insight into what's going wrong. And I don't want my bugs to languish (it's bad enough that my pretty straightforward PRs do that).
Is the number
34related to something in the language server implementation? It doesn't appear to be a local line/column number (it's at least stable for my file).
The diagnostic message can have a code which is an integer | string and that is what the 34 is.
It's hard to file good bugs w/o having some vague insight into what's going wrong.
I agree. I think in this particular case things worked out fine. You have a Dockerfile that you believe is getting linted incorrectly and you provided the full file for someone to try. I would consider you having done everything within your power to help someone diagnose and reproduce the problem.
And I don't want my bugs to languish (it's bad enough that my pretty straightforward PRs do that).
I can certainly understand that desire.