No source given
The one label that changes behaviour, and it is missing
- title
- myapp
- description
- An app
- source
Generate the standard image labels. Most of them are documentation; one of them changes what a registry does with your image.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The one label that changes behaviour, and it is missing
Silently ignored by every tool that reads the label
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
They change on every build, so every layer below them is rebuilt every time.
Instead:Put them last, after everything that should stay cached.
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.
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.
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.
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.
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.
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.
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.