Pipeline: Expose retries to the the Task/TaskRun

[IdanAdar]

Expected Behavior

For the value of retries to be available at runtime so I could track it and potentially run different code flows depending in the current retry counter.

Actual Behavior

Currently not exposed.

[wlynch]

/kind feature

Hi! Thanks for the feature request!

Can you describe in a little more detail what your use case is? e.g. are you looking for retry information to be exposed to running step containers, or the Tekton controller itself to be used with Conditions?

Thanks! :D

[IdanAdar]

I would like to use it in steps, yes. I did not think about exposing it in Conditions, but I don't see why not...

We have some tasks (with a single step) that will be retried on failure. In this case though, depending on the number of attempts done I may want to dispatch a different notification, so knowing the current attempt # will help me accomplish that.

[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]

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]

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

[IdanAdar]

@wlynch why?

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

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.

[yaoxiaoqi]

I'm interested in the issue. Can I work on this?
/assign @yaoxiaoqi

[ImJasonH]

Just to clarify, is the end goal to enable something like this Pipeline?

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: retry-param
spec:
  tasks:
  - name: retry-me
    retries: 5
    taskSpec:
      steps:
      - image: busybox
        script: echo 'I am attempt number $(context.retry-count) of $(context.retries)' && exit 1

In this example, when the Pipeline is run, it should run 5 TaskRuns, the first one printing I am attempt 1 of 5, the last one printing I am attempt 5 of 5 -- is that roughly the feature you're looking for @IdanAdar ?

(In the example above, the names of the placeholders are made up, we'd probably find a better name for both of them)

[bobcatfish]

potentially run different code flows depending in the current retry counter.

The idea of changing the behavior of a Task based on the retries seems like a bad idea but it's hard to say without knowing the specific use case.

However making this information available seems pretty reasonable either way? Might be worth bringing up in an API working group at least ( @tektoncd/core-maintainers )

[IdanAdar]

For example, we have an e2e tests task that runs continuously.

If it fails, it runs again and again thanks to the number of retries.

Whenever it fails, it sends a Slack notification. I want it to send the notification only if it fail the defined number of retires. Exposing the number will enable me so.

[vdemeester]

potentially run different code flows depending in the current retry counter.

The idea of changing the behavior of a Task based on the retries seems like a bad idea but it's hard to say without knowing the specific use case.

However making this information available seems pretty reasonable either way? Might be worth bringing up in an API working group at least ( @tektoncd/core-maintainers )

@bobcatfish Agreed, I think we should discuss this during the API working group, but I don't see any reason for not exposing this.

[sbwsg]

We discussed this in the API WG. There were no objections surfaced during that time and people seemed to generally agree that there are use cases for this. So I think we can go ahead with a short TEP / implementation.

[afrittoli]

@yaoxiaoqi are you still looking into this issue?

[sbwsg]

There's a TEP open at https://github.com/tektoncd/community/pull/239

[yaoxiaoqi]

@yaoxiaoqi are you still looking into this issue?

Yes, I'm still working on this. There is a short TEP under reviewing as Scott says.

@sbwsg Thanks for providing the information!

[bobcatfish]

Hey @IdanAdar we had some back and forth on this in the TEP (https://github.com/tektoncd/community/pull/239) and ultimately have been leaning toward NOT adding this functionality for now - if you're able to take a look it would be great to get your take on this (just because the TEP PR is closed for now doesn't mean it has to stay that way)

[IdanAdar]

If the community is not interested then OK. It only means we need to have our own internal counters making the tekton retry useless and it just won't be used... because it's too limited.

[bobcatfish]

Hey @IdanAdar ! Quick update, based on your feedback we've reopen-ed https://github.com/tektoncd/community/pull/239 and @yaoxiaoqi is planning to go ahead and update the proposal with a couple tweaks https://github.com/tektoncd/community/pull/239#issuecomment-744586570

[yaoxiaoqi]

@yaoxiaoqi is planning to go ahead and update the proposal with a couple tweaks tektoncd/community#239 (comment)

Thanks @bobcatfish ! The TEP is already updated. Next I will work on implementing it.