Change:
Given a cronjob created with a scedule of "0 6 *" that failed at last run (status.lastSuccessfulTime is now "before" status.lastScheduleTime). Then I trigger the cronjob by hand and this jobs ends successfully. However status.lastSuccessfulTime is not updated, thus making it difficult to monitor failed cronjobs. status.lastSuccessfulTime should be updated with a timestamp of the succeeded job endTime Install the attached files: Wait until cronjob has actually trigged, test with to see that lastScheduleTime and lastSuccessfulTime are populated ok (as expected). Then apply the fail config-map, now the job will not complete OK: Again wait until cronjob has trigged automatically, observe to see that lastScheduleTime is updated but lastSuccessfulTime is not. Then apply the "OK" configmap and then create the job by hand: when the job has finished and completed ok, observe that lastSuccessfulTime is still not updated. Wait until next schedule and observe that the field is now updated. No response <details</details<detailsTested on kind cluster on Mac </details<details</details<details</details<details</details<details</details
Had to upload the files as .txt files as github wouldn't accept .yaml or .yml files
(Double-check: I may read wrong messagess ) /sig apps
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : When I tried without the prefix in the job name, the status is updated. /sig apps /area job not sure if this is a bug or an expected behavior. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/area workload-api/cronjob
I have just tested in my kind cluster and neither with the same naming pattern as the normal jobs (which apparently isn't epoch) or with epoch - this will not trigger a update of the field. I have also tested it on another cluster (rke2 based) and here I'm not able to get the field updated no matter which naming pattern I use.
Sorry for the mistake. I can repro the problem you have and not related to the prefix. /cc
/assign
/remove-sig apps /sig cli
/triage accepted

Discussion:
// this is ok because we know exactly how we want to be serialized TypeMeta: metav1.TypeMeta{APIVersion: batchv1.SchemeGroupVersion.String(), Kind: "Job"}, ObjectMeta: metav1.ObjectMeta{ <del> Name:        o.Name, Annotations: annotations, Labels:      cronJob.Spec.JobTemplate.Labels, OwnerReferences: []metav1.OwnerReference{ { APIVersion: batchv1.SchemeGroupVersion.String(), Kind:       "CronJob", Name:       cronJob.GetName(), UID:        cronJob.GetUID(), }, }, </del> <ins> Name:            o.Name, Annotations:     annotations, Labels:          cronJob.Spec.JobTemplate.Labels, OwnerReferences: []metav1.OwnerReference{*metav1.NewControllerRef(cronJob, batchv1.SchemeGroupVersion.WithKind("CronJob"))}, </ins> }, Spec: cronJob.Spec.JobTemplate.Spec, }

expected: &batchv1.Job{ TypeMeta: metav1.TypeMeta{APIVersion: batchv1.SchemeGroupVersion.String(), Kind: "Job"}, ObjectMeta: metav1.ObjectMeta{ <del> Name:        jobName, Annotations: map[string]string{"cronjob.kubernetes.io/instantiate": "manual"}, OwnerReferences: []metav1.OwnerReference{ { APIVersion: batchv1.SchemeGroupVersion.String(), Kind:       "CronJob", Name:       cronJob.GetName(), UID:        cronJob.GetUID(), }, }, </del> <ins> Name:            jobName, Annotations:     map[string]string{"cronjob.kubernetes.io/instantiate": "manual"}, OwnerReferences: []metav1.OwnerReference{*metav1.NewControllerRef(cronJob, batchv1.SchemeGroupVersion.WithKind("CronJob"))}, </ins> }, Spec: batchv1.JobSpec{ Template: corev1.PodTemplateSpec{