You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ContainerRegistry: Separate registry operations into ImageSource and ImageDestination protocols (#148)
Motivation
----------
Currently, `RegistryClient` handles uploading and downloading container
images to and from a registry. In fact, `containertool` creates two
clients: one is used only to download images from the source repository,
and the other is used only to upload images to the destination.
Registries are read/write, but in the future we may need to handle
sources of images which are read-only or write-only - for example when
writing a container image out to an archive on disk.
This change adds two new protocols, splitting up the operations needed
to upload and download images. This allows for future clients which
cannot handle both sets of operations.
Modifications
-------------
* Add new `ImageSource` and `ImageDestination` protocols, defining the
functions needed to download and upload images, respectively.
* Consolidate the `RegistryClient` extensions which implement the
`ImageSource` and `ImageDestination` protocols.
Result
------
Refactoring. No functional change, but responsibilities of different
objects are clearer.
Test Plan
---------
Existing tests continue to pass.
/// Upload an image configuration record to the registry.
107
+
/// - Parameters:
108
+
/// - image: Reference to the image associated with the record.
109
+
/// - configuration: An image configuration record
110
+
/// - Returns: An `ContentDescriptor` referring to the blob stored in the registry.
111
+
/// - Throws: If the blob upload fails.
112
+
///
113
+
/// Image configuration records are stored as blobs in the registry. This function encodes the provided configuration record and stores it as a blob in the registry.
0 commit comments