tektoncd
Feature Request: tkn debug
While there are certainly features of tkn that aid with debugging a TaskRun or PipelineRun, there isn't, in my opinion, something similar to the experience of using an IDE debugger when both developing Tekton resources (e.g. pipelines/tasks) and figuring out what is wrong with an already developed Tekton resource.
I imagine this feature having the following requirements:
- Ability to pause and restart pipelines/tasks before or after a task in the case of a pipeline or a step in the case of a task. Think of this as a breakpoint in an IDE.
- The ability to see the values of variables when a pipeline/task stops at a breakpoint.
- It would be nice to be able to do all of these actions from an IDE. This is obviously not a requirement for the CLI, but
tknwould likely be used by any IDE that wishes to implement this experience. So it's something that should be kept in mind.
As mentioned previously, I think there are two use cases where I see this making sense: Development - Actually developing pipelines/tasks. The ability to have a similar debugging experience to what developers are familiar with when developing applications I think would greatly help developers actually create CI/CD resources. Management - Helping teams figure out what has caused a pipeline/task that is actually used for a development process to break.
I do not have any hard opinions on how this could be implemented from a user experience perspective from the CLI. I think this issue can be used to help further define this feature and discuss ideas.
/kind feature
I'd love to have that too but as you said that goes beyond what CLI can offers and this would need some discussions first on pipeline
Related which i think would be helpful for debugging if implemented https://github.com/tektoncd/cli/issues/126
Yes, there are a lot of aspects of this that would need to be worked out in pipeline as well as IDE extension projects.
I have seen issues around pausing pipelineruns/taskruns:
- Design: Suspend PipelineRun and TaskRuns after creation
- Design and implement paused Task execution until condition is met
However, none of these quite fulfill this use case, so to your point, an issue/discussion would need to take place there first. I thought of the CLI as a logical middle ground for introducing this idea, but it certainly requires support from other projects.
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.
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: 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.
Just found out this issue. Did you discuss more about it in any meeting? I am working on the Tekton plugin in IntelliJ and i would be really interested in having this implemented. Can i help you somehow? Let me know.
@lstocchi This has not been discussed further than the discussion in the issue. I still think the idea is valid and would be great to have, but I do think there are some changes in pipelines that may need to come first. I still do not think there is the ability to pause TaskRuns or PipelineRuns, which is needed to support this. However, I imagine we could start putting more emphasis on certain ideas around since there is interest from IDE extension communities.
Maybe we can start by aggregating what would be needed from a pipelines perspective first and then begin to build out more requirements for this feature. I think a TEP would be good for this issue as there are a lot of moving parts.