Image repository monitoring libary

[alexmt]

Is your feature request related to a problem? Please describe.

The image registry monitoring is a generic functionality required in multiple projects. I propose extracting this functionality into a separate Git repository and making it available as a library.

Describe the solution you'd like

The library should provide the following features:

• Finding a tag of a given image that meets criteria such as pattern match constraints, semver constraints, time constraints (newest), etc. The existing functionality already covers all these requirements, and no semantic changes are required.

• Ability to extract the image digest along with the tag that is found.

• Caching of extracted image information. I propose considering two different strategies:

  • A cache where entries are keyed by tag. (current strategy)
  • Optionally, pull the digest along with the selected tag and use it for caching. This supports the edge case where the tag is mutable.

• Support for different registries: the ability to interact with various registries, including those that do not fully comply with the Docker Registry HTTP API V2.

The library's source code should be hosted under the argoproj-labs organization. Alternatively, we might consider argoproj. The following repository names are proposed: container-registry-scanner, oci-scanner, oci-utils, oci-go-sdk, registry-scanner. Please vote in the comments!

As a summary we need functionality of packages below. Minimal changes are required - just one request to support caching using digests in addition to tags. Packages (list may be incomplete - listing packages here just to explain the idea) :

• pkg/image
• pkg/registry
• pkg/tag
• pkg/version

Describe alternatives you've considered

Import the Image Updater itself as a library. This is not ideal since it also introduces all transitive dependencies. Another issue is introducing changes: the Image Updater is a product that provides end-to-end functionality for a specific use case, so it has its own release cycle, which makes it difficult to release changes specific to image registry monitoring functionality.

Additional context

The first customer of the library would be https://github.com/akuity/kargo!

[alexmt]

For additional context, here is @jessesuen 's opinion (I personally 100% agree ) about how Kargo & Image Updater are related: #645 (comment)

TLDR: projects are not competing and targeting different use cases. Extracting shared functionality into the library would help both Kargo & Image Updater.

[christianh814]

+1 for registry-scanner

[krancour]

Proposing image-selector since this selects a single image from a repository based on specified criteria.

[jaideepr97]

+1 for registry-scanner as well

[jannfis]

How about oci-toolkit?

[krancour]

@jannfis wouldn't we want the library to continue working with registry v1 and v2? (Ok... maybe v1 can go.)