Add opt-in patch mode for CronJob reload strategy

[akshat-kumar-singhal]

Summary

• Add new annotation reloader.stakater.com/cronjob-reload-strategy: patch that allows CronJobs to use patch mode instead of creating immediate Jobs
• When enabled, patches the CronJob template and recreates any running Jobs owned by the CronJob
• Default behavior (creating immediate Job) remains unchanged for backward compatibility

Problem

When a ConfigMap/Secret is updated, Reloader creates an immediate Job from the CronJob template. This causes:

1. Out-of-schedule job execution
2. "Orphan" jobs not tracked by CronJob controller's history limits
3. Bypasses CronJob's concurrencyPolicy

Solution

Add an opt-in patch strategy that:

1. Patches the CronJob template (so future scheduled runs get new config)
2. Finds and recreates any running Jobs owned by the CronJob
3. Does NOT create an extra immediate Job

Usage

apiVersion: batch/v1                                                                                                                                                           
kind: CronJob                                                                                                                                                                  
metadata:                                                                                                                                                                      
  name: my-cronjob                                                                                                                                                             
  annotations:                                                                                                                                                                 
    reloader.stakater.com/auto: "true"                                                                                                                                         
    reloader.stakater.com/cronjob-reload-strategy: "patch"                                                                                                                     

Test plan

• Unit tests for new callback functions (PatchCronJob, RecreateRunningJobsForCronJob, UpdateCronJobWithRunningJobs)
• Unit tests for CronJob patch templates
• Unit tests for GetCronJobPatchFuncs and GetCronJobCreateJobFuncs
• Manual test: Deploy CronJob WITHOUT annotation, update ConfigMap → verify immediate Job is created
• Manual test: Deploy CronJob WITH patch annotation, update ConfigMap → verify CronJob template is patched, NO immediate Job created

[trvrnrth]

@akshat-kumar-singhal You may be interested in #1098 in which I take a simpler approach to job re-creation by way of deleting the pods for any active jobs and allowing the job controller to handle re-creation as appropriate. This has the advantage of retaining the history of any given job and also properly respecting job restart policies.

[akshat-kumar-singhal]

@akshat-kumar-singhal You may be interested in #1098 in which I take a simpler approach to job re-creation by way of deleting the pods for any active jobs and allowing the job controller to handle re-creation as appropriate. This has the advantage of retaining the history of any given job and also properly respecting job restart policies.

Thanks @trvrnrth for reviewing this. Though I don't agree with the current implementation (spawning of an orphan job on config update), #1098 breaks that behaviour. Would you consider adding another annotation to handle this?