Open ReubenBond opened 6 months ago
@karolz-ms - where did we ever land with DCP deciding to pull a new version for a tag, even if it is cached locally? See https://github.com/dotnet/aspire/issues/1997#issuecomment-1918263447:
As for stale image checks, we have prior art for that in our VS/VS Code container extensions. We could have the AppHost or DCP could do a similar staleness check in the background and emit warnings during the application run if stale images are detected.
@karolz-ms - where did we ever land with DCP deciding to pull a new version for a tag, even if it is cached locally? See #1997 (comment):
As for stale image checks, we have prior art for that in our VS/VS Code container extensions. We could have the AppHost or DCP could do a similar staleness check in the background and emit warnings during the application run if stale images are detected.
@eerhardt AFAIK the comment above was just a feature idea. We don't even have a backlog item to think about it yet. The improvement we DO have in plans (for shortly-post-GA release) is to expose container startup logs in the dashboard. So for the problem like above, it would hopefully make it clearer what went wrong.
Is there a workaround for this that anyone knows about?
Delete the container image from docker and it'll re-pull the latest image.
I ran into this when running our Aspire tests locally:
This results in the test hanging for 10 minutes, presumably waiting for the container to start (it will never start). This issue occurs because machine already has an older version of the Cosmos DB container image and we are specifying the tag
"latest"
and not periodically forcing a re-pull.Perhaps we should check image age and re-pull images older than a certain period. Either way, assuming Cosmos DB does not change its behavior, this will result in broken dev inner-loops and CI pipelines down the line.