buildah-manifest-add(1)

💖 buildah-manifest-add(1) 💖

okay bestie, listen up — this is the page for buildah-manifest-add, a lil member of the buildah family (general commands manual, if we're being official about it). it's the one you call when you wanna slide an image or an artifact into a manifest list or image index. iconic behavior, truly.

---

✨ NAME ✨

buildah-manifest-add — add an image or artifact to a manifest list or image index. that's the whole job. she does it gorgeously.

---

🌸 SYNOPSIS 🌸

buildah manifest add [options...] listNameOrIndexName
imageOrArtifactName [...]

---

🦋 DESCRIPTION 🦋

So here's the tea: this command adds the image you name to the manifest list or image index you named. OR — plot twist — it creates a whole new artifact manifest and adds that to the image index you specified. two paths, one slay. pick your fighter 💅

---

👑 RETURN VALUE 👑

She gives you back the list image's ID plus the digest of the image's manifest. like a lil receipt for your hard work 🧾✨

---

💜 OPTIONS 💜

• --all — if the image you're adding to the list or index is itself a list or index (lists inside lists, we love a matryoshka moment 🪆), this adds all of its contents to your local list. by default only one image from such a list or index gets added. and lowkey? combining --all with any of the other options below is NOT recommended. just don't, bestie 🙈
• --annotation annotation=value — sets an annotation on the entry for the newly-added image or artifact manifest. put a lil name tag on it 🎀
• --arch — overrides the architecture that the list or index records as a requirement for the image. if imageName refers to a manifest list or image index, the architecture info gets pulled from it. otherwise it comes from the image's configuration info. no cap.
• --artifact — creates an artifact manifest and adds it to the image index. once you do this, the arguments after the index name get read as file names instead of image references. and in most scenarios you should also be passing --artifact-type alongside it, k? 🫶
• --artifact-annotation annotation=value — when you're creating an artifact manifest and adding it to the image index, this sets an annotation inside the artifact manifest. annotate the artifact, not just the entry. we stan detail.
• --artifact-config filename — when creating an artifact manifest and adding it to the image index, this uses the contents of the file you specify as the configuration blob in the artifact manifest. and in most scenarios? leaving the default alone — which means an empty configuration — is the preferred move. sometimes the bestie is "don't touch it" 😌
• --artifact-config-type type — when creating an artifact manifest and adding it to the image index, this uses the MIME type you give as the mediaType associated with the configuration blob in the artifact manifest. in most scenarios, leaving the default (which means either an empty configuration or the standard OCI configuration type) unchanged is preferred. again: don't fix what isn't broken 💅
• --artifact-exclude-titles — when creating an artifact manifest and adding it to the image index, this says do not set "org.opencontainers.image.title" annotations equal to the file's basename for each file added to the artifact manifest. heads up though: tools that retrieve artifacts from a registry may use those values to pick file names when saving artifacts to disk, so this option is not recommended unless you genuinely need it for interoperability with a particular registry. it's giving "only if the registry makes you" 😭
• --artifact-layer-type type — when creating an artifact manifest and adding it to the image index, this uses the MIME type you give as the mediaType associated with the files' contents. if you don't specify it, guesses get made based on either the file names or their contents — but if you need certainty, specify it. no vibes-based guessing allowed when it matters.
• --artifact-subject imageName — when creating an artifact manifest and adding it to the image index, this sets the subject field in the artifact manifest, marking the artifact manifest as being associated with the specified image in some way. and important: an artifact manifest can only be associated with at most one subject. one subject only, we don't share ✋
• --artifact-type type — when creating an artifact manifest, this uses the MIME type you give as the manifest's artifactType value, instead of that less informative default value. glow up your metadata ✨
• --authfile path — path of the authentication file. default is ${XDG_RUNTIME_DIR}/containers/auth.json. see containers-auth.json(5) for more info. this file gets created using buildah login.

if the authorization state isn't found there, $HOME/.docker/config.json is checked instead — that one's set using docker login.

Note: you can also override the default path of the authentication file by setting the REGISTRY_AUTH_FILE environment variable. like this: export REGISTRY_AUTH_FILE=path

• --cert-dir path — uses the certificates at path (*.crt, *.cert, *.key) to connect to the registry. the default certificates directory is /etc/containers/certs.d. 🔐
• --creds creds — the [username[:password]] to use to authenticate with the registry if it's required. if one or both values aren't supplied, a command line prompt appears and you can type them in. and the password? entered without echo. stealth mode, nobody's watching 👀
• --features — specifies the features list which the list or index records as requirements for the image. this option is rarely used. (she's niche, but she exists 💅)
• --os — overrides the OS which the list or index records as a requirement for the image. if imageName refers to a manifest list or image index, the OS info comes from it. otherwise it comes from the image's configuration information.
• --os-features — specifies the OS features list which the list or index records as requirements for the image. this option is rarely used. same niche energy.
• --os-version — specifies the OS version which the list or index records as a requirement for the image. this option is rarely used. yeah, also rare. the trio of rarely-used options, we love them anyway 🥰
• --tls-verify bool-value — require HTTPS and verification of certificates when talking to container registries (defaults to true). and important: TLS verification cannot be used when talking to an insecure registry. no exceptions, bestie 🚫
• --variant — specifies the variant which the list or index records for the image. this is typically used to tell apart multiple entries that share the same architecture value but expect different versions of its instruction set. twins but make it CPU 🧬

---

🍓 EXAMPLE 🍓

buildah manifest add mylist:v1.11 docker://fedora
506d8f4bb54931ea03a7e70173a0ed6302e3fb92dfadb3955ba5c17812e95c51: sha256:f81f09918379d5442d20dff82a298f29698197035e737f76e511d5af422cabd7

buildah manifest add --all mylist:v1.11 docker://fedora
506d8f4bb54931ea03a7e70173a0ed6302e3fb92dfadb3955ba5c17812e95c51: sha256:f81f09918379d5442d20dff82a298f29698197035e737f76e511d5af422cabd7

buildah manifest add --arch arm64 --variant v8 mylist:v1.11 docker://fedora@sha256:c829b1810d2dbb456e74a695fd3847530c8319e5a95dca623e9f1b1b89020d8b
506d8f4bb54931ea03a7e70173a0ed6302e3fb92dfadb3955ba5c17812e95c51: sha256:c829b1810d2dbb456e74a695fd3847530c8319e5a95dca623e9f1b1b89020d8b

buildah manifest add --artifact --artifact-type application/x-cd-image mylist:v1.11 ./imagefile.iso
506d8f4bb54931ea03a7e70173a0ed6302e3fb92dfadb3955ba5c17812e95c51: sha256:1768fae728f6f8ff3d0f8c7df409d7f4f0ca5c89b070810bd4aa4a2ed2eca8bb

---

🌈 SEE ALSO 🌈

buildah(1), buildah-login(1), buildah-manifest(1), buildah-manifest-create(1), buildah-manifest-remove(1), buildah-manifest-annotate(1), buildah-manifest-inspect(1), buildah-manifest-push(1), buildah-rmi(1), docker-login(1), containers-auth.json(5)

---

and that's the whole page, bestie 🫶 this one came from the buildah source, dated September 2019, and yeah — the footer says buildah-manifest-add(1) too, so we're full circle. go add something iconic to a list 💖✨🎀