Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
buildah-manifest-add(1)      General Commands Manual	 buildah-manifest-add(1)

NAME
     buildah-manifest-add - Add an image or artifact to a manifest list or image
     index.

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

DESCRIPTION
     Adds the specified image to the specified manifest list or image index,  or
     creates an artifact manifest and adds it to the specified image index.

RETURN VALUE
     The list image's ID and the digest of the image's manifest.

OPTIONS
     --all

     If the image which should be added to the list or index is itself a list or
     index, add all of the contents to the local list.	By default, only one im-
     age  from such a list or index will be added to the list or index.  Combin-
     ing --all with any of the other options described below is NOT recommended.

     --annotation annotation=value

     Set an annotation on the entry for the newly-added image or artifact  mani-
     fest.

     --arch

     Override  the architecture which the list or index records as a requirement
     for the image.  If imageName refers to a manifest list or image index,  the
     architecture  information will be retrieved from it.  Otherwise, it will be
     retrieved from the image's configuration information.

     --artifact

     Create an artifact manifest and add it to the image index.  Arguments after
     the index name will be interpreted as file names rather than as image  ref-
     erences.	In  most  scenarios,  the  --artifact-type option should also be
     specified.

     --artifact-annotation annotation=value

     When creating an artifact manifest and adding it to the image index, set an
     annotation in the artifact manifest.

     --artifact-config filename

     When creating an artifact manifest and adding it to the  image  index,  use
     the  specified  file's  contents  as the configuration blob in the artifact
     manifest.	In most scenarios, leaving the default value, which signifies an
     empty configuration, unchanged, is the preferred option.

     --artifact-config-type type

     When creating an artifact manifest and adding it to the  image  index,  use
     the  specified MIME type as the mediaType associated with the configuration
     blob in the artifact manifest.  In  most  scenarios,  leaving  the  default
     value,  which  signifies  either an empty configuration or the standard OCI
     configuration type, unchanged, is the preferred option.

     --artifact-exclude-titles

     When creating an artifact manifest and adding it to the image index, do not
     set "org.opencontainers.image.title" annotations equal to the file's  base-
     name  for	each  file added to the artifact manifest.  Tools which retrieve
     artifacts from a registry may use these values to choose  names  for  files
     when  saving artifacts to disk, so this option is not recommended unless it
     is required for interoperability with a particular registry.

     --artifact-layer-type type

     When creating an artifact manifest and adding it to the  image  index,  use
     the  specified  MIME  type as the mediaType associated with the files' con-
     tents.  If not specified, guesses based on either the files names or  their
     contents  will be made and used, but the option should be specified if cer-
     tainty is needed.

     --artifact-subject imageName

     When creating an artifact manifest and adding it to the  image  index,  set
     the subject field in the artifact manifest to mark the artifact manifest as
     being  associated	with the specified image in some way.  An artifact mani-
     fest can only be associated with, at most, one subject.

     --artifact-type type

     When creating an artifact manifest, use the specified MIME type as the man-
     ifest's artifactType value instead of the less informative default value.

     --authfile path

     Path of the authentication  file.	Default  is  ${XDG_RUNTIME_DIR}/contain-
     ers/auth.json.  See containers-auth.json(5) for more information. This file
     is created using buildah login.

     If the authorization state is not found there, $HOME/.docker/config.json is
     checked, which is set using docker login.

     Note: You can also override the default path of the authentication file  by
     setting   the   REGISTRY_AUTH_FILE   environment	variable.   export  REG-
     ISTRY_AUTH_FILE=path

     --cert-dir path

     Use 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  re-
     quired.  If one or both values are not supplied, a command line prompt will
     appear and the value can be entered.  The password is entered without echo.

     --features

     Specify  the  features list which the list or index records as requirements
     for the image.  This option is rarely used.

     --os

     Override 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 in-
     formation will be retrieved from it.  Otherwise, it will be retrieved  from
     the image's configuration information.

     --os-features

     Specify  the  OS  features list which the list or index records as require-
     ments for the image.  This option is rarely used.

     --os-version

     Specify the OS version which the list or index records as a requirement for
     the image.  This option is rarely used.

     --tls-verify bool-value

     Require HTTPS and verification of certificates when  talking  to  container
     registries  (defaults to true).  TLS verification cannot be used when talk-
     ing to an insecure registry.

     --variant

     Specify the variant which the list or index records for  the  image.   This
     option  is  typically  used  to  distinguish between multiple entries which
     share the same architecture value, but which expect different  versions  of
     its instruction set.

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-cre-
     ate(1), buildah-manifest-remove(1), buildah-manifest-annotate(1),	buildah-
     manifest-inspect(1),  buildah-manifest-push(1),  buildah-rmi(1), docker-lo-
     gin(1), containers-auth.json(5)

buildah 			 September 2019 	 buildah-manifest-add(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=buildah-manifest-add&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>

home | help