CIPD is package deployment infrastructure. It consists of a package registry and a CLI client to create, upload, download, and install packages.
A CIPD package has a package name (e.g. “infra/tools/foo”) and a list of content-addressed instances (e.g. “bec8e88201949be06b06174178c2f62b81e4008e”), where slashes in package names form a hierarchy of packages, and an instance is a ZIP file with the package file contents.
CIPD is different from apt-get, brew, nuget, pip, npm, etc. in that it is not tied to a specific OS or language.
A package instance can be referenced by a tuple (package name, version), for example when installing a package. A version is one of:
"bec8e88201949be06b06174178c2f62b81e4008e"; this is also called the instance ID.
"git_revision:deadbeef", if it is unique among all instances of the package. Read more about tags below.
"latest", see below.
A package instance can be marked with tags, where a tag is a colon-separated key-value pair, e.g.
"git_revision:deadbeef". If some tag points to only one instance, such tag can be used as version identifier.
A package can have git-like refs, where a ref of a package points to one of the instances of the package by id. For example, chrome-infra continuous builders always update the
"latest" ref of a package to the instance that they upload.
If a package is platform-specific, the package name should have a
/<os>-<arch> suffix, for example “infra/tools/cipd/linux-amd64”. The
os part can be
arch can be
armv6l. See the ensure package docs for accepted os and arch values.
Some CIPD client subcommands accept a package name “directory” that ends with slash, e.g. “infra/tools/cipd/”, and apply a change to all packages in that directory non-recursively.
A package directory can have an ACL that applies to packages in that directory and inherited by subdirectories. ACLs can be read/controlled by the CIPD client.
The API definition with a lot of additional details is available here.