Change Behavior of What --keep Saves from Deletion

[danielhelfand]

Version and Operating System

tkn Version: v0.8.0

Expected Behavior

The --keep option for tkn pr ls and tkn tr ls should delete the least recent TaskRuns or PipelineRuns as opposed to the most recent. It is more common to want to keep more recent entries than later ones.

An alternative suggestion would be for --keep to keep by something other than a number. An example being a date range or a variety of filter options.

Whatever the choice, the deletion approach of --keep should be changed from its current deletion approach.

An example is as follows for keeping most recent TaskRuns:

tkn tr ls:

NAME                STARTED          DURATION     STATUS               
sleep1s-run-qkh5n   31 seconds ago   26 seconds   Succeeded   
sleep1s-run-t7zxw   32 seconds ago   27 seconds   Succeeded   
sleep1s-run-8svzx   33 seconds ago   32 seconds   Succeeded   
sleep1s-run-vr6v9   33 seconds ago   31 seconds   Succeeded   
sleep1s-run-87kwl   34 seconds ago   31 seconds   Succeeded   
sleep1s-run-zczw8   35 seconds ago   32 seconds   Succeeded   
sleep1s-run-dhqdl   36 seconds ago   34 seconds   Succeeded   
sleep1s-run-n725h   37 seconds ago   33 seconds   Succeeded   
sleep1s-run-98d2r   38 seconds ago   32 seconds   Succeeded   
sleep1s-run-5rxfg   39 seconds ago   33 seconds   Succeeded

tkn tr delete --all --keep 3 & tkn tr ls (Most recent are saved):

NAME                STARTED          DURATION     STATUS               
sleep1s-run-qkh5n   31 seconds ago   26 seconds   Succeeded   
sleep1s-run-t7zxw   32 seconds ago   27 seconds   Succeeded   
sleep1s-run-8svzx   33 seconds ago   32 seconds   Succeeded   

Actual Behavior

An example is as follows:

tkn tr ls:

NAME                STARTED          DURATION     STATUS               
sleep1s-run-qkh5n   31 seconds ago   26 seconds   Succeeded   
sleep1s-run-t7zxw   32 seconds ago   27 seconds   Succeeded   
sleep1s-run-8svzx   33 seconds ago   32 seconds   Succeeded   
sleep1s-run-vr6v9   33 seconds ago   31 seconds   Succeeded   
sleep1s-run-87kwl   34 seconds ago   31 seconds   Succeeded   
sleep1s-run-zczw8   35 seconds ago   32 seconds   Succeeded   
sleep1s-run-dhqdl   36 seconds ago   34 seconds   Succeeded   
sleep1s-run-n725h   37 seconds ago   33 seconds   Succeeded   
sleep1s-run-98d2r   38 seconds ago   32 seconds   Succeeded   
sleep1s-run-5rxfg   39 seconds ago   33 seconds   Succeeded

tkn tr delete --all --keep 3 & tkn tr ls (Least recent are kept):

NAME                STARTED          DURATION     STATUS               
sleep1s-run-n725h   37 seconds ago   33 seconds   Succeeded   
sleep1s-run-98d2r   38 seconds ago   32 seconds   Succeeded   
sleep1s-run-5rxfg   39 seconds ago   33 seconds   Succeeded

[ghost]

I agree on the ordering, that the default should be newest-first. Maybe introduce a flag for sorting oldest-first?

An alternative suggestion would be for --keep to keep by something other than a number. An example being a date range or a variety of filter options.

I like this idea a lot. An example syntax for this might be something like tkn tr delete --all --keep since=30d which would protect any TaskRuns started in the last 30 days. Maybe the --keeps can be chained? Example:

# Delete any TaskRun older than 30d that doesn't have the given label
tkn tr delete --all --keep since=30d --keep label="tekton.dev/do-not-delete"

Going with key-value would also allow the existing behaviour with a numeric argument to persist:

# Delete all but the 3 newest TaskRuns in the last 30d that don't have the given label
tkn tr delete --all --keep 3 --keep since=30d --keep label="tekton.dev/do-not-delete"

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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.