Reduce boliler-plate code in cronjobs configurations

[afrittoli]

Expected Behavior

It should be possible to add new cronjobs by specifying a list of variables in some format (YAML / properties).

Actual Behavior

Creating a new cronjob requires creating a new folder, a kustomize.yaml and a YAML to patch the base cronjob manifest.

Additional Info

The problem with the boiler-plate code is that is more error-prone and on the long run it's harder to maintain. We will be adding more and more cronjobs for CD or services and resources, and it would be good to have a smart solution for this.

It may be just a matter of more advanced use of kustomize, or perhaps we need a generic task to build the kustomize patch files from property files.

[afrittoli]

It is also difficult to know which of the resources in the plumbing repo are automatically deployed and which not. Having some kind of convention of folder structure, or metadata in json/yaml files might help maintain the repo.

I'm thinking something of the sort:

[folder-with-resource]
  - README.md
  - resource (YAML templates, helm values, or else)
  - .tektoncd

Where .tektoncd is a YAML/JSON/ENV file that specifies a list of:

• name of the base cronjob
• name suffix for the target cronjob
• resource prefix to be applied
• variables to be set in the cronjob
• frequency
• schedule [optional?]

We would have a script that generates the cronjobs from each entry in the .tektoncd files and a check that verifies that those cronjobs exists in the PR.

Alternatively we could push the .tektoncd file to a configmap, and have the base cronjob loop over all entries in the configmap and trigger all of them. The downside of this approach would be that we would lose the ability to schedule at different times / frequencies.

[afrittoli]

Another way to simplify cronjobs would be to put the static data into dedicated bindings, and keep only the job name in the json sent by the cronjob. We could use a CEL filter then to direct the request to the correct binding.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.