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
{
"instruction": "EXPOSE",
"count": 1,
"level": "info",
"message": "There is no 'EXPOSE' instruction",
"description": "Without exposed ports how will the service of the container be accessed?",
"reference_url": [
"https://docs.docker.com/engine/reference/builder/",
"#expose"
]
}
I wonder, what is the big idea behind reference_url being a list, rather than a usual single-string URL as one might expect?
Duplicated anchors
Relatedly: I find that, inconsistently, some reference_url responses contain just one anchor marker #, while some other responses contain it twice, like here:
This makes it yet harder to consume reference_url in code — for no apparent reason.
Breaking change of schema?
Finally: can this be fixed at all? I.e. will maintainers merge a patch changing reference_url format to simple string?
Considering that --json is obviously made for programmatic consumption — changing the schema may potentially break some [careless] consumers. Although I'm unsure how numerous are consumers of this... rather strange reference_url schema, and if they'd want to migrate to a scalar string anyway.
I'm asking to gain understanding (whether this is an oversight or an intentional decision) before I introduce one more consumer in ALE's dockerfile_lint integration. Notice that it currently ignores reference_url altogether (probably because of its weird and unwieldy format). Should I encode string catenation and ## replacement there? Can I, future-compatibly, expect a plain string instead?
The text was updated successfully, but these errors were encountered:
Hi! Take this JSON output for example:
I wonder, what is the big idea behind
reference_url
being a list, rather than a usual single-string URL as one might expect?Duplicated anchors
Relatedly: I find that, inconsistently, some
reference_url
responses contain just one anchor marker#
, while some other responses contain it twice, like here:This makes it yet harder to consume
reference_url
in code — for no apparent reason.Breaking change of schema?
Finally: can this be fixed at all? I.e. will maintainers merge a patch changing
reference_url
format to simple string?Considering that
--json
is obviously made for programmatic consumption — changing the schema may potentially break some [careless] consumers. Although I'm unsure how numerous are consumers of this... rather strangereference_url
schema, and if they'd want to migrate to a scalar string anyway.I'm asking to gain understanding (whether this is an oversight or an intentional decision) before I introduce one more consumer in ALE's dockerfile_lint integration. Notice that it currently ignores
reference_url
altogether (probably because of its weird and unwieldy format). Should I encode string catenation and##
replacement there? Can I, future-compatibly, expect a plain string instead?The text was updated successfully, but these errors were encountered: