Question/Proposal: Step Resource

[danielhelfand]

Currently, the Task resource consists of Steps that each run in a separate container. I am wondering why Steps are not a separate resource that could be defined separately from a Task and then reused as part of several Tasks.

This would follow the design considerations of other Tekton resources that are highly reusable, such as Tasks and PipelineResources.

What is the reasoning for not having a Step resource?

[bobcatfish]

@danielhelfand I think this is a really interesting idea - maybe relevant to @ahpook 's interests as well?

What is the reasoning for not having a Step resource?

We've been focusing on a Task as the most reusable unit; additionally the container images within the Steps are kind of another reusable unit, so I think we haven't seen a clear reason to make a Step itself reusable.

Maybe you could give some examples of where this could be useful?

[vdemeester]

@bobcatfish This is kind of related to Task composition and issues like #1367 (Allow for TaskReference Interpolation within Pipeline). I think the idea would be able to define some common step that need to be done in a Task, so that they can be shared and re-use easily.

I wonder if it should be a PipelineResource or its own type, usable/injectable in the Task spec. And as it is "arbitrary" (Step being a ContainerSpec or a script), it would make it possible to do anything (like replacing any other type of resources, kinda 😝 ).

[danielhelfand]

I think the main use case I see for this is, as @vdemeester has mentioned, is about being able to define a step once and have it be reusable across tasks. Being able to write the step once and then be able to have a StepRef as part of a task would help to avoid having to write out a whole step each time.

Granted, it's debatable how much this would be worth it considering how much has already been done around having tasks as the most basic unit, but I think promoting reuse of images, resource allocation for the step, and individual commands would be nice to package as some type of resource.

[danielhelfand]

Following up on this, I think a good use case of this could be cli tools used as part of a task. For instance, currently there is a task for gcloud and also one for oc. These tasks basically only execute one command, but I think the better use case would be to have these tasks represented as reusable steps.

[bobcatfish]

I think this could be pretty cool, though it's hard for me to imagine exactly what it would look like. @danielhelfand and/or anyone else, would you be interested in putting together a proposal with maybe some examples of what this would be like?

[danielhelfand]

@bobcatfish Sure! Do you have any particular format for a proposal, or would you like a high level examples of how I imagine this?

[bobcatfish]

@danielhelfand either is great - we have some suggestions for what we try to look for in proposals in https://github.com/tektoncd/community/blob/master/process.md#proposing-features

but basically as much/little as you think is reasonable :D and the working group (https://github.com/tektoncd/community/blob/master/working-groups.md#general) is a great place to discuss this out loud if you'd prefer that route

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

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.

[bobcatfish]

I don't think we've ever really established whether or not we want to do this, it comes up every once in a while in conversation but it still feels (to me at least!) like we have no use cases for this that are compelling enough for us to do it