No source given
The one label that changes behaviour, and it is missing
- title
- myapp
- description
- An app
- source
Docker OCI Image Labels Generator
Generate the standard image labels. Most of them are documentation; one of them changes what a registry does with your image.
image-labels.txt
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
A free-text licence
Silently ignored by every tool that reads the label
- licenses
- Apache 2.0 with exceptions
- source
- https://github.com/acme/widget
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Omitting org.opencontainers.image.source when publishing to GHCR
The package is not linked to the repository, so it has no README, no source link, and does not follow the repository's visibility settings.
Instead:Set it to the repository URL exactly.
Hard-coding the revision or the build date
They are wrong from the second build on, and a wrong revision sends whoever is debugging to the wrong commit.
Instead:Pass them as build args and set the labels from those.
Putting the build-arg labels near the top of the Dockerfile
They change on every build, so every layer below them is rebuilt every time.
Instead:Put them last, after everything that should stay cached.
org.opencontainers.image.source is the load-bearing one
On GitHub Container Registry it is what links a published package to its repository. Without it the package page has no README, no link back to the code, and it does not inherit the repository's visibility.
The per-build labels have to come from build args
revision, created and version change on every build, so hard-coding them means they are wrong from the second build onwards. A wrong revision label is worse than none, because it points an investigation at the wrong commit.
And they belong at the very end of the Dockerfile
A label that changes every build invalidates the cache for every layer below it. Put the static ones early if you like and the build-arg ones last, so a new commit hash does not rebuild the dependency install.
One LABEL instruction, not ten
Each one is a separate history entry and a separate cache boundary. Labels add no layer, so the size cost is nil and the cache cost is real: changing the first of ten invalidates the nine below.
licenses expects an SPDX identifier
The specification says so, and scanners and compliance tooling parse it as one. A free-text value is silently ignored by everything that reads it, which defeats the point of a standard label.
Labels are published with the image
They are in the image config, so docker inspect shows them without running anything. An internal ticket URL or an internal hostname in a label goes out with the image.
The Dockerfile is not the only place
docker build --label sets them too, which is useful for values a pipeline knows and the Dockerfile does not. Where both set the same key, the command line wins.
Related docker tools
Docker Container Image Reference Parser Is that a registry or a Docker Hub user? Docker Image Config Viewer Anyone who can pull can read your Env Docker Logging Driver Generator json-file never rotates Dockerfile Non-Root USER Generator Numeric, or Kubernetes rejects it Docker BuildKit Cache Mount Generator apt deletes the cache you just mounted Docker BuildKit Secret Mount Generator ARG is in docker history forever
All 36 docker tools