-
Notifications
You must be signed in to change notification settings - Fork 750
Add Push and PushPrereq pipeline steps for ContainerRegistryResource #13306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13306Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13306" |
|
@copilot Bleh, we need to have the ContainerRegistryReferenceAnnotation on all resources so that we can correctly compute the remote image tag during the push phase. Add a PushPrereq step that will add the ContainerRegistryReferenceAnnotation to resources that don't already have it when a single container registry exists in the app model. When multiple registries exist, throw an exception that the user must call |
Done in ed1e587. The |
|
Does this break when you have 2 compute environments now? |
Probably, lol. TBH, I haven't gotten that far. I'm just trying to get the end-to-end over in aspire-image-push working before layering on things. My intuition tells me that as a fall out of this PR we'll need to model the Azure Container Registry that is implicitly in the compute environments as an explicit thing and always model the push steps on a resource that implements IContainerRegistry instead of within the compute environments. |
|
@copilot We need to make sure that the PushPrereq runs unconditionally on compute resources that need a push. Currently, GetResourcesToPush introduces a gap in the implementation because we will never wire up the PipelineStepConfiguration for the PushPrereq if there isn't already a ContainerRegistryReferenceAnnotation set (which is done by the PushPrereq). |
Fixed in 335a826. Refactored |
src/Aspire.Hosting/ApplicationModel/ContainerRegistryResource.cs
Outdated
Show resolved
Hide resolved
src/Aspire.Hosting/ApplicationModel/ContainerRegistryResource.cs
Outdated
Show resolved
Hide resolved
| /// <param name="builder">The distributed application builder.</param> | ||
| /// <param name="name">The name of the container registry resource.</param> | ||
| /// <returns>The created <see cref="AzureContainerRegistryResource"/>.</returns> | ||
| public static AzureContainerRegistryResource CreateDefaultContainerRegistry(IDistributedApplicationBuilder builder, string name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CreateDefaultAzureContainerRegistry
9485950 to
6cdddc1
Compare
19a0685 to
fb319be
Compare
fb319be to
19f38c8
Compare
|
OK, I tested the changes in 9c45f96 against the following scenarios.
|
|
|
This fails without .WithContainerRegistry(acr); var builder = DistributedApplication.CreateBuilder(args);
var acr = builder.AddAzureContainerRegistry("acr");
var cache = builder.AddRedis("cache");
#pragma warning disable ASPIRECOMPUTE003 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
var server = builder.AddProject<Projects.FeBackend_Server>("server")
.WithReference(cache)
.WaitFor(cache)
.WithHttpHealthCheck("/health");
var webfrontend = builder.AddViteApp("webfrontend", "../frontend")
.WithReference(server)
.WaitFor(server)
.WithExternalHttpEndpoints();
server.PublishWithContainerFiles(webfrontend, "wwwroot");
builder.Build().Run(); |
|
@davidfowl Yeah, we're currently only setting the RegistryTargetAnnotation when you call |
Description
Adds pipeline infrastructure for pushing container images to
ContainerRegistryResourceinstances. The registry resource now directly creates push steps for all resources that reference it.Key changes:
WellKnownPipelineSteps.PushandWellKnownPipelineSteps.PushPrereqconstantsContainerRegistryResourceregistersPipelineStepAnnotationto create per-resource push stepsContainerRegistryResourceregistersPipelineConfigurationAnnotationto wire Build → Push dependenciesPushunconditionally depends onPushPrereqto ensure annotations are set up before any push operationsPushPrereqstep automatically addsContainerRegistryReferenceAnnotationto resources that don't have one when a single registry exists (required for correct remote image tag computation during push)GetResourcesToPushonly includes resources withContainerRegistryReferenceAnnotationmatching the target registry.WithContainerRegistry()annotationExample usage:
Checklist
<remarks />and<code />elements on your triple slash comments?doc-ideatemplatebreaking-changetemplatediagnostictemplateOriginal prompt
Container Registry Push Pipeline Step Plan
Overview
This plan proposes adding support for pushing container images to
ContainerRegistryResourceinstances through a well-known pipeline step. TheContainerRegistryResourcewill directly register pipeline steps for all resources that reference it.Motivation
Currently, the
ContainerRegistryResourceserves as a reference for container registries but doesn't participate in the deployment pipeline. To enable deployment scenarios where containers need to be pushed to external registries (Docker Hub, GHCR, private registries), we need to:The reference implementation from https://github.com/captainsafia/aspire-image-push demonstrates this need with a custom pipeline step that pushes images to a parameterized container registry.
Goals
WellKnownPipelineSteps.Pushas a well-known pipeline stepContainerRegistryResourceto directly create push steps for all resources that require image pushDeploymentTargetAnnotationfor consistencyAPI Design
1. Add Well-Known Pipeline Step
Add a new constant to
WellKnownPipelineSteps.cs:2. ContainerRegistryResource Pipeline Integration
Update
ContainerRegistryResourceto directly create push steps for all resources that reference it: