projectatomic / dockerfile_lint

MIT License
86 stars 11 forks source link

Why reference_url in JSON output is *list* ? #134

Open ulidtko opened 4 years ago

ulidtko commented 4 years ago

Hi! Take this JSON output for example:

  {
    "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:

"reference_url": [
      "http://docs.projectatomic.io/container-best-practices/#",
      "#_using_semi_colons_vs_double_ampersands"
    ],

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?

JonZeolla commented 3 years ago

I have the same question; interested in the background.