Change:
if !options.Local { helper := resource.NewHelper(client, mapping) <del> patchedObject, err := helper.Patch(namespace, name, patchType, patchBytes) </del> <ins> _, err := helper.Patch(namespace, name, patchType, patchBytes) </ins> if err != nil { return err } if cmdutil.ShouldRecord(cmd, info) { <del> if err := cmdutil.RecordChangeCause(patchedObject, f.Command()); err == nil { // don't return an error on failure.  The patch itself succeeded, its only the hint for that change that failed // don't bother checking for failures of this replace, because a failure to indicate the hint doesn't fail the command // also, don't force the replacement.  If the replacement fails on a resourceVersion conflict, then it means this // record hint is likely to be invalid anyway, so avoid the bad hint resource.NewHelper(client, mapping).Replace(namespace, name, false, patchedObject) </del> <ins> // don't return an error on failure.  The patch itself succeeded, its only the hint for that change that failed // don't bother checking for failures of this replace, because a failure to indicate the hint doesn't fail the command // also, don't force the replacement.  If the replacement fails on a resourceVersion conflict, then it means this // record hint is likely to be invalid anyway, so avoid the bad hint patch, err := cmdutil.ChangeResourcePatch(info, f.Command()) if err == nil { helper.Patch(info.Namespace, info.Name, api.StrategicMergePatchType, patch) </ins> } } count++

Discussion:
Hi, Deployment patching with doesn't show up in the deployment rollout history: first: after: Is it a bug? Should it show up? Thanks, Peter
cc
Which kubernetes and kubectl releases? Did the patch actually trigger a rollout?
I also run the command from CI with the latest . So the problem affects the v1.2.3 kubectl as well
We should also fix the way we sort revisions - 10 should be after 9, not 1.
Can confirm this. The issue is that the patch isn't updating , so the rollout history will just copy the value from the previous version. If you started with you get that for the patches. In my case I have a different line repeated. Builds 7 and 8 were built with different . I'm not sure why the patch worked once. Command I am calling is:
If no one is working on patch - i can try to make one.
I'll like to work on this issue if you haven't started yet
Actually never mind I can look at something else :)
Hi, i see that you are the author of the following comment. I think that currently every valid change cause is discarded because of version conflict. Maybe you have some information why it happens?
command instead generates a patch to update then applies that.
It was the same for patch, but for some reason was changed.
The intent was two fold. First, prevent the change-cause from ever failing patch the CLI command. change-cause isn't authoritative and the patch took hold, so a non-zero return code is inappropriate. Second, if the resource version change post-patch, before the update, the change-cause is unknown, something else touched it after the fact. A command that issues a instead of an could very easily break the history since patches will attempt to reapply themselves regardless of resource version in the face of conflicts. The object returned from the patch operation is the one that we use to avoid hitting a resource conflict with ourselves.

Truth be told, I don't feel very strongly about getting the history right since it can be changed anyone with write access to the object, includes secrets that should be elided (--token for instance), ignores environment variables which affect outcome, ignores the actual path used to locate the binary you're running, and references paths that are only good from one location on one machine, so if you want to switch it back to a second patch, I don't mind as long as a failure to update the object doesn't cause a non-zero return from the command.
Could there be a race between the call and the deployment updating itself to action the changes? On 19 May 2016 9:47 pm, "David Eads" wrote: