Add support for specifying an image pull policy for containers

[danegsta]

Description

Adds a new ContainerImagePullPolicyAnnotation and WithImagePullPolicy builder API to allow configuring the container image pull policy for a given container resource. The supported pull policy settings are Default, Always, and Missing. A pull policy of Always will result in the container image always being pulled when the container is run, regardless of whether a version of the image is cached locally. Missing will only pull images if there is no cached version locally (and therefore you may not be using the latest version of the image). Default represents the default behavior if no policy is specified. Currently that will be the default behavior for your container runtime (which is generally the same as Missing for both Docker and Podman), however that could change in future Aspire releases.

When building a new image from a Dockerfile, Always will also force pulling any base images as part of the build, Missing will use the default behavior of only pulling images that aren't available locally, and Default will again match the runtime's default build process behavior.

Example:

container.WithImagePullPolicy(ImagePullPolicy.Always);

Fixes #7350

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No (it would be difficult to validate in unit tests whether Docker had pulled an image)
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

[davidfowl]

Does this mean we’ll get the pulling status separately in the ux?

[danegsta]

Does this mean we’ll get the pulling status separately in the ux?

This PR won't give any pulling status updates, just allow controlling the behavior of when new images are pulled. Getting image pull progress from the Docker or Podman CLI is non-trivial as they only provide detailed breakdowns when running in a TTY environment.

One thing we may want to consider is making container images a first class DCP resource so that we can control when to pull them independent of running the container that requires the image; that way we can differentiate between pulling an image and general container startup when reporting status (even if we can't give detailed progress on the image pull).

[eerhardt]

Are there tests we can write for this?

At a minimum at least calling this API and ensuring the annotation is there. Ideally, if we can tell what data gets sent to DCP, we could ensure the image pull policy is set correctly.

[eerhardt]

@mitchdenny - do we usually have immutable annotation classes? Should this be a ctor parameter and a get-only property?

[eerhardt]

Just 2 comments from me. Once those are addressed, I think this change looks good to go in.