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
However, I notice the RestartPods target occurs before the image is fully published to my ACR, resulting in a race condition that sometimes Kubernetes beats, meaning the old image is deployed instead of the new...
What should my AfterTargets be set to if I want it to only run the rollout commands after the container is fully published to ACR?
The text was updated successfully, but these errors were encountered:
I'd need to take a look at a binlog to double-check, but my first recommendation would be the PublishContainer target - that's the target that actually creates + pushes container images to the desired destination, whether that's local daemon, tarball, or remote registry.
Is there any way you can get an https://aka.ms/binlog and use the viewer to take a look? I added a target just like yours to a sample project I had, and then published that project with dotnet publish -t:PublishContainer and see the target firing as I expect:
Hello we have a project like many others publishing docker images to kubernetes.
To try to make developers life easier I added the following to my pubxml:
However, I notice the RestartPods target occurs before the image is fully published to my ACR, resulting in a race condition that sometimes Kubernetes beats, meaning the old image is deployed instead of the new...
What should my AfterTargets be set to if I want it to only run the rollout commands after the container is fully published to ACR?
The text was updated successfully, but these errors were encountered: