The primary reason for this change is to fix a bug detecting ProgressDeadlineExceeded. I was accidentally checking for that in the Type when it should have been in the Reason.
While I was testing it out (Deployments failing because the v1.3.8 image doesn't exist yet), I noticed some inconsistent behavior that led to a bit of refactoring.
It appears that if you have maxUnavailable: 1 in your Deployment yaml, it can cause issues where ProgressDeadlineExceeded is never raised. I added a warning to notify since it is something that can be handled in the yaml.
The other change was getting the most recent update time from the ManagedFields. This might have been what we were looking for all along with the original waitForReady method, but I didn't investigate to thoroughly. Before adding it the rollback would sometimes exit with the ProgressDeadlineExceeded error still in the status from the previous failed deployment.
Let me know what you think. Sorry to complicate things.
HI @omrikiei,
The primary reason for this change is to fix a bug detecting
ProgressDeadlineExceeded. I was accidentally checking for that in the Type when it should have been in the Reason.While I was testing it out (Deployments failing because the v1.3.8 image doesn't exist yet), I noticed some inconsistent behavior that led to a bit of refactoring.
It appears that if you have
maxUnavailable: 1in your Deployment yaml, it can cause issues whereProgressDeadlineExceededis never raised. I added a warning to notify since it is something that can be handled in the yaml.The other change was getting the most recent update time from the ManagedFields. This might have been what we were looking for all along with the original
waitForReadymethod, but I didn't investigate to thoroughly. Before adding it the rollback would sometimes exit with theProgressDeadlineExceedederror still in the status from the previous failed deployment.Let me know what you think. Sorry to complicate things.