Enforce Dockerfile labels with lint about build-tools HOT 4 OPEN

We often have the problem that we don't know where the source code for an image lives.

"Often"? For example?

There's a more-or-less standard way of providing this information, using Docker labels. We should do that.

I wouldn't consider the label-schema.org stuff to be widely accepted or a standard. I'd describe it as something that was started started, that didn't get wide adoption, and that people have now moved on from. For instance, there are only 11 threads on its email list[1], these tags aren't "supported" in anyway by the docker hub, and there are only 1.2k images using them[2].

[1] https://groups.google.com/forum/#!forum/label-schema
[2] https://microbadger.com/labelschema

I much prefer the naming convention approach to solving this problem.

from build-tools.

Examples:

• a couple of months ago, me trying to find where the code for tomwilkie/git-sync is
• last month, Paul trying to find where weaveworks/gfdatasource was

A naming convention could work, but the issue is that we have several:

• name is repo, e.g. weaveworks/kubediff -> github.com/weaveworks/kubediff
• name is subdir of unmentioned repo, e.g. quay.io/weaveworks/alertmanager -> github.com/weaveworks/monitoring
• name is subproject of mentioned repo, e.g. quay.io/weaveworks/cortex-alertmanager -> github.com/weaveworks/cortex

At the very least.

from build-tools.

Suggested minimum useful set of labels:

LABEL works.weave.source-path="/grafana/Dockerfile" \
      org.label-schema.schema-version="1.0" \
      org.label-schema.vcs-url="https://github.com/weaveworks/service-conf"

Where works.weave.source-path is the path to the Dockerfile for this image.

from build-tools.

@marccarre has been working on https://github.com/weaveworks-experiments/imagediff to help with this process.

from build-tools.