-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support alternative implementations of a specific Task #1323
Comments
Maybe a little low-tech ... but a Task could have a step that internally wraps a dynamically named (or even generated) Task or Pipeline, run it and then copy it's inputs and outputs (and maybe even logs) back out to the containing TaskRun. It would definitely be a bit of work to support traceability but I think still possible with clever labelling. |
Nice idea, that would move the granularity back; but without the benefit of running on the same node. I think there are multiple possible ways to implement this - but whatever the solution I'd like it to be very much declarative - so that its clear from the pipeline/task/step specs what we expect to happen. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
I think this is still a valid use case. |
@afrittoli I still don't totally understand this use case - this means that someone has written a Pipeline and they want to use the entire Pipeline as-is, but they want to swap out individual Tasks. I guess I don't totally understand why it's not worth writing a different Pipeline in that case. The Task specialization proposal COULD include this, but for the question of "when do you want this specialization", it seemed like "when running the Pipeline" was the one point at which no one really needed to do the specialization. Do you have some use cases today (maybe for dogfooding?) where you need this? |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
I wonder if this is related to some of the discussions we're having in #2298, specifically about being able to make changes to a Task without having to change the Pipeline (e.g. if you use an OCI reference in a Pipeline and want to try out some changes to a Task before it's published) |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
Description and motivation
A Tekton
Task
has an interface that is defined by the collection of its inputs (resources + params) and outputs (resources). It should be possible to replace aTask
in aPipeline
with a different one as long as their inputs and outputs are compatible.Tekton however does not really provide any way to switch the implementation of a
Task
in aPipeline
dynamically or without significantly altering thePipeline
definition.The feature proposed here introduces a way to dynamically select a compatible Task implementation at run time based on inputs or conditions. For instance a release pipeline could use a different Task to tag images depending on the container registry it's running against.
State of the Art
There are ways this could be partially achieved today using
Conditions
.A number of
Task
s, each with aCondition
could be defined in thePipeline
. However there is no way to enforce the conditions being mutually exclusive, so it may be that multipleTask
s are executed at the end. Another issue is with the output resources. AnyTask
that depend on the outputs of theTask
s with conditions, would not have a way to specify whichTask
its inputs are coming from.Use Cases
Possible Implementations
One way to handle this could be to allow for the Task name in the pipeline spec to be dynamic, i.e. only defined at runtime. It could be built out of parameters or resources.
Alternatively a new kind of
MultiTask
could be implemented, that in its definition references all the possibleTask
implementations and the condition for their selection, in a way that enforces mutual exclusion. Consumers of theMultiTask
outputs would reference to theMultiTask
name as source of their inputs.It might be possible to introduce
AbstractTasks
, i.e. Tasks with interface spec but no actual steps in them, but I fear that would be to rigid, an suffer similar type of issue as abstract classes in object orient programming.Notes
This may sound similar to #215 - at least from the issue name - but it's a different feature - even if there may be points of overlap.
The text was updated successfully, but these errors were encountered: