TEP-0048: task results without results - problem statement #240

pritidesai · 2020-10-22T07:38:21Z

Listing use cases and problem statement for task results without results based on the latest API changes.

teps/0028-task-results-without-results.md

bobcatfish

Thanks for writing this up @pritidesai !

I think this is pretty reasonable (with a small tweak that id rather call the field something like "default" than "value") (tho I really like @chhsia0's alternative as well!!)

I'd also like to explore another alternative (I added a comment with more details): what if we provide the entire status of the pipelinerun on disk in a file for these use cases? These Tasks seem to want to:

Run regardless of the skipped + failure status of the non-finally Tasks
Want to access results from one or more Tasks (if they succeeded)
Probably also want to look at the execution status of one or more Tasks

If these are true, I'm not sure that simple variable substitution will be enough to support them, i.e. these Tasks will probably be highly bespoke, and it might work better to give them a file on disk to introspect

it might help to look examples of one or more of these Tasks (the boskos Tasks might be too simple)

bobcatfish · 2020-10-26T16:39:39Z

teps/0028-task-results-without-results.md

+          value: $(params.second)
+      results:
+        - name: sum
+          value: 0


could we call this something like default instead of value? I would think that value would override the result created by the Task, but it sounds like what we want is to use this only in the case where the Task fails or is skipped (or does not produce a result?)

"or does not produce a result?" --> if the Task succeeds but does not produce a result, is this default used? (I suggest in the first iteration we don't support that)

yup sure, lets call it default instead of value. Yes use this default value when a task does not produce a result.

We have an issue to declare such task (does not produce a result) failure: tektoncd/pipeline#3497. This fix will prevent executing any other dag tasks and no need for any defaults. But finally tasks are still executed and you suggest not using default in finally as well?

bobcatfish · 2020-10-26T16:42:32Z

teps/0028-task-results-without-results.md

+This example shows that `B` is guarded with task results from `A` where `A` was skipped but is it really a possible
+scenario? When this `pipeline` says continue executing `B` even though `A` was skipped, why would `B` be guarded with a
+task result from `A`?
+


another alternative would be to move the "default" specification into the "params" section in the pipelineTask instead, e.g.:

spec: params: - name: owner-name default: "the-best-owner" tasks: - name: boskos-acquire taskRef: name: boskos-acquire params: - name: owner-name value: $(params.owner-name) - name: do-stuff-with-resource taskRef: name: do-stuff-with-resource params: - name: resource-name value: $(tasks.boskos-acquire.results.leased-resource) finally: - name: boskos-release taskRef: name: boskos-release params: - name: leased-resource value: $(tasks.boskos-acquire.results.leased-resource) default: "fake-awesome-project"

if we wanted to make this work for when expressions, we'd need some way of expressing defaults in when expressions as well which is the big downside of this approach

one upside of this approach tho is that it lets the consumer of the value decide what to do with it vs. having the producer understand that the consumer still wants to run

another alternative would be to provide/require a completely different way of accessing results for the use cases above

i.e. if you want to look at a result value, and you want to run regardless of the state of the producing task (i.e. even if failed, skipped, etc.), we provide another way to provide this info, e.g.:

write a file to disk with the status of the entire pipelinerun

provide variable replacement for the entire pipelinerun status

i think that providing something like (1) might be a reasonable alternative here; i have a feeling that the tasks that we want to create for the use case above might be more complex than just the boskos example we are including

@chhsia0 also mentioned another interesting option in the working group today which i think it worth exploring: introducing a syntax for the variable replacement that allows a default to be specified, e.g.:

$(tasks.boskos-acquire.results.leased-resource | fake-awesome-project)

I really like that this option would let us both:

Let the consumer of the value decide how to handle the case where it is not provided

Work for when expressions AND params

However if we go that route i think we'd also want to take into account #1393 i.e. what would this syntax look like in a world where we have more types than just strings and can do stuff like array indexing

I also liked the idea of expressing a default value in the variable substitution syntax itself, especially if it looks somewhat similar to Bash syntax, e.g. $(tasks.boskos-acquire.results.leased-resource:-fake-awesome-project}. This is a well-known feature of shell scripting so people would just "get it" without a lot of explanation required. I guess the downside is that you need to specify the default on every reference as opposed to having a single place where you could set it as in Priti's proposal.

another alternative would be to move the "default" specification into the "params" section in the pipelineTask instead

Yup, this can also allow specifying separate defaults for each reference, but downside with when expressions is significant as well. How would we allow having defaults with when expressions then?

thank you for the suggestion, have included as one of alternatives

I liked the proposed options. But also defaulting on the producer and consumer side do not have to be orthogonal.
Defaulting a result would be an helper for task author to ensure a result is always provided, that the author has enough context in the task to be able to do that meaningfully.
Defaulting a variable value would be a helper the task author (or runner) to provide a default value for situations where the pipeline / pipelinerun context is required to provide a meaningful default.
Both could be implemented as separate features.

bobcatfish · 2020-10-26T16:46:46Z

teps/0028-task-results-without-results.md

+scenario? When this `pipeline` says continue executing `B` even though `A` was skipped, why would `B` be guarded with a
+task result from `A`?
+
+## References


another alternative would be to provide/require a completely different way of accessing results for the use cases above

i.e. if you want to look at a result value, and you want to run regardless of the state of the producing task (i.e. even if failed, skipped, etc.), we provide another way to provide this info, e.g.:

write a file to disk with the status of the entire pipelinerun

provide variable replacement for the entire pipelinerun status

i think that providing something like (1) might be a reasonable alternative here; i have a feeling that the tasks that we want to create for the use case above might be more complex than just the boskos example we are including

(1) is being tracked here I think we still have a use case for that feature and will have a separate TEP for it.

But in this context, (1) again adds extra responsibility of parsing metadata to consumer task and does not work with when expressions.

GregDritschler · 2020-10-26T17:32:28Z

teps/0028-task-results-without-results.md

+
+A minor alternative to the proposal in which specifying `results` default values is limited to `optional` task `params`,
+instead, allow specifying default values for both `required` and `optional` task `params`. And skip the task when
+default values are not specified while results are missing.


What would be the reason to not allow the default result value to be used with a required parameter? The pipeline author might be trying to reuse a task that does not have a default for a param value. It seems to me like the pipeline author should be able to pass the default result value anyway.

It was adhering to the same concept of required v/s optional params. Dropped this limitation.

teps/0028-task-results-without-results.md

afrittoli

Thank you for this!
This will add great value to Tekton usability!

The main comment that I have is that I feel that we should not restrict this to optional task parameters; that seems to be the least interesting use case to me. Mandatory task params is where I see most of the value.

teps/0028-task-results-without-results.md

afrittoli · 2020-11-19T17:38:20Z

teps/0028-task-results-without-results.md

+
+### Non-Goals
+
+This proposal is not offering a solution without any use case.


I'm not sure I understand this 🙏

afrittoli · 2020-11-19T17:39:39Z

teps/0028-task-results-without-results.md

+
+### Goals
+
+Identify a set of use cases for `finally` and `continueAfterSkip` without task results and design a common solution


I feel the goal could be more generic about default value for results, and finally and continueAfterSkip could go into use cases? Even more so since continueAfterSkip is not a feature we support yet.

teps/0028-task-results-without-results.md

afrittoli · 2020-11-19T17:53:05Z

teps/0028-task-results-without-results.md

+
+## Proposal
+
+Enable `pipeline` author to specify a default value for a `task result` in case of a missing result. Pipeline author


+1
I agree the default value here should be controlled by the pipeline author and not by the task author

teps/0028-task-results-without-results.md

afrittoli · 2020-11-19T18:03:13Z

teps/0028-task-results-without-results.md

+tasks in a `pipeline`. `params` in a `task` can be declared as required and optional. Required `params` does not allow
+any defaults and have to be initialized at the `pipeline` or `pipelineRun` level.
+
+The proposal is designed on the similar lines, when a `param` is declared `optional` at the `task` level and referring to the


I'm afraid I don't understand the reasoning behind this.
If a parameter is declared as optional in the Task, by definition it is acceptable not to pass any value to it.

Optional parameters are those least in need of a default, because if the expression injected by the pipeline depends on something not available (like a result), the pipeline could simply not pass any value, and it would work, because it's optional.

Mandatory parameters instead cause a Task failure if not passed. If the pipeline author binds a mandatory task parameter to a result from another task, we need a way for the pipeline author to supply a default value (if they want) in case the result in question is not available.

Optional parameters are those least in need of a default, because if the expression injected by the pipeline depends on something not available (like a result), the pipeline could simply not pass any value, and it would work, because it's optional.

Optional param at the task level referring to task result in a Pipeline is considered as required i.e. if a task result is not initiated, pipeline stops executing even if a referenced param was optional at the task level.

afrittoli · 2020-11-19T18:08:53Z

teps/0028-task-results-without-results.md

+          value: $(task.add.results.sum)
+```
+
+No default for a `required` task param (referring to a task result) allowed. If a task result is missing, `pipeline`


I'm afraid I don't understand the reason behind this restriction.

It should be up to the pipeline author whether to specify the default or not.
Assuming the pipeline about, you could have the following combinations:

x param type result default multiply execution

mandatory supplied executed

mandatory not supplied skipped

optional supplied executed

optional not supplied executed

teps/0028-task-results-without-results.md

afrittoli · 2020-11-23T10:54:25Z

/test pull-community-teps-lint

jmcshane · 2020-12-31T13:28:26Z

teps/0028-task-results-without-results.md

+
+#### Story 2
+
+Need user story for `finally` task with optional `param` referring to a task result.


Pipeline that scans code and packages within a container image.
The pipeline fails if the scan does not pass a certain threshold
The task still collects and publishes results even if the scan task fails by outputting the scan summary to a result string
A finally task would consume the task result on success and failure and publish that information to an external consumer for review.

bobcatfish · 2021-01-25T17:18:58Z

/assign @jerop

( @afrittoli would you like to be assigned as a reviewer for this one?)

afrittoli · 2021-02-01T14:25:32Z

/test pull-community-teps-lint

bobcatfish · 2021-02-02T17:03:38Z

/assign

vdemeester

The one thing I have trouble wrapping my head around is the use of results as field. It's similar in name and "shape" with the results field for Tasks and Pipelines, but it doesn't have the same behaviour, it is a "failsafe" for result to have a value if the task failed.
Maybe we should use another name ?

Also, I am a bit fuzzy on what is the limitation for Option F with the when expression 🤔

vdemeester · 2021-02-05T13:02:37Z

teps/0048-task-results-without-results.md

+ This works well without having task results default. The `param` in the task has full control over where its value
+coming from and what is the default if it's not initialized.
+ Works with `continueAfterSkip` feature.
+- Cannot be extended to `when` expressions since task result in `when` expression is not mapped to any `param` in the


I am not sure I understand this one 🤔

vdemeester · 2021-02-05T13:04:50Z

teps/0048-task-results-without-results.md

+
+ This alternative allows task result consumer to decide the default value based on its use case v/s task
+  result producer defining common default for all consumers.
+- Not compatible with `when` expression.


Can we add more detail on why it's not compatible ? I'm not sure I understand 😝

vdemeester · 2021-02-05T13:06:55Z

teps/0048-task-results-without-results.md

+      results:
+        - name: sum
+          value: 0


What happens if add-task define a result name sum and what happens if add-task doesn't define a result name sum ?

bobcatfish

Finally got a chance to take a look!! My main feedback is that it's hard to weigh the options without having some really compelling use cases - is there any way we can gather some more (and/or add more detail to the existing ones) (maybe you have some more in mind that are motivating this TEP @pritidesai ?)

bobcatfish · 2021-02-18T21:35:26Z

teps/0048-task-results-without-results.md

+#### Story 1
+
+For a cleanup use case, `finally` task receives the project name, or the configuration name as a `task result` from
+the `acquire` task. If `acquire` task fails to acquire any resources, `cleanup` is skipped.


i think there's some detail missing here - it seems like if the resources weren't acquired, you don't want to do the cleanup?

bobcatfish · 2021-02-18T21:39:26Z

teps/0048-task-results-without-results.md

+      params:
+        - name: imageRef
+          value: "$(tasks.build-image.results.builtImage)"
+```


the example ALMOST makes sense to me but a couple things i think might be missing:

The name of the image returned by build-image seems like it would be targetImage? If so it doesnt seem like deploy-image actually cares about the result of build-image, this seems more like a case for wanting to apply the when expression to only build-image

I also don't totally understand the context of this use case - why do we want to build an image only if it doesn't exist? (is the image getting periodically deleted? or is it like built once a day and named after the day?) any more details you can provide might help

bobcatfish · 2021-02-18T21:41:38Z

teps/0048-task-results-without-results.md

+         value: $(params.owner-name)
+     results:
+      - name: leased-resource
+        value: "fake-awesome-project"


i think using value here doesn't quite imply the defaulting behavior we're adding - maybe default ?

bobcatfish · 2021-02-18T21:43:26Z

teps/0048-task-results-without-results.md

+Pros/Cons:
+
+- Consumer task has no control over default values.
+- Task consuming such default value cannot identify whether its an invalid value or a default value.


i dont understand why that is, can you explain more?

bobcatfish · 2021-02-18T21:43:44Z

teps/0048-task-results-without-results.md

+
+Instead of specifying defaults for task results, leverage task `param` default value. When the task fails and the `param`
+referring to task results has a default, use that `param` default. If that `param` is required and no default specified,
+skip the task.


could you include an example?

bobcatfish · 2021-02-18T21:44:01Z

teps/0048-task-results-without-results.md

+### Option C
+
+No defaults allowed (neither in the `task` producing results nor in the `pipelineTask` for the `task` producing results),
+just skip `finally` task with a reason when a task result is missing.


is this the current functionality?

bobcatfish · 2021-02-18T21:44:41Z

teps/0048-task-results-without-results.md

+The `cleanup` is necessary when the resources are acquired but not needed if the acquisition fails. This option is
+proposing introducing `when` expression to `finally`. `Cleanup` task in `finally` checks the execution status of
+`acquire` task, and guards `cleanup` if `acquire` failed. This proposal helps avoid dealing with missing task results
+in `finally` i.e. no default or no zero values for task results needed.


i dont totally follow this one, maybe an example would help?

bobcatfish · 2021-02-18T21:48:41Z

teps/0048-task-results-without-results.md

+This example shows that `B` is guarded with task results from `A` where `A` was skipped but is it really a possible
+scenario? When this `pipeline` says continue executing `B` even though `A` was skipped, why would `B` be guarded with a
+task result from `A`?
+


Another proposal that came up (I'm not sure where?? i feel like @chhsia0 was involved but not sure) is to introduce a defaulting syntax when using the variable interpolation for results, e.g. something like:

$(tasks.foo.results.bar?somedefault) (or maybe instead of somedefault we require reference to another var?)

I might be kinda crazy but i actually like this option b/c it puts the control completely on the consuming PipelineTask (like option b) but also works for when expressions

if we go this route hopefully we could borrow the syntax from somewhere else

this is interesting -- just wondering how it'd look like if the default was a variable

would it be $(tasks.foo.results.bar?$(params.someDefault)) 🙃 -- maybe $(tasks.foo.results.bar?params.someDefault) is better?

but then how would this look like if we add support for array results proposed in #477?

(back to focusing on the problem statement only lol)

bobcatfish · 2021-02-18T21:49:09Z

teps/0048-task-results-without-results.md

+```
+
+
+## Design Details


can we include pros and cons for the proposed option? (seems like we have them for the alternatives)

afrittoli · 2021-02-22T17:12:42Z

/assign @afrittoli

jromero · 2021-03-05T21:20:00Z

teps/0048-task-results-without-results.md

+          value: $(task.add.results.sum)
+```
+
+### User Stories


I have a user story that seems to apply to this TEP as I'm hoping it would enable the flow I desire.

I have a pipeline that conditionally forks between two different tasks. Both of the tasks provide a result of APP_IMAGE_DIGEST. Now within my pipeline I'd like to propagate that result as the result of the pipeline.

Currently, I can't find a way to achieve what I'm desiring. The proposed solution should allow me to execute a consolidation task on the pipeline that can check to see which task results are present and set those as the Pipeline results. Is my thinking correct?

Pipeline │ ┌─────────────────────┼──────────────────────────┐ │ │ │ │ ┌─────▼──────┐ │ │ │ │ │ │ │ git-clone │ │ │ │ │ │ │ └─────┬──────┘ │ │ │ │ │ ┌─────────────┴───────────────┐ │ │ │ (condition) │ │ │ ┌─────▼──────┐ ┌──────────┴────────┐ │ │ │ │ │ │ │ │ │ buildpacks │ │ buildpacks-phases │ │ │ │ │ │ │ │ │ └─────┬──────┘ └──────────┬────────┘ │ │ │ │ │ │ └──────────────┬──────────────┘ │ │ results │ results │ │ │ │ └──────────────────────┼─────────────────────────┘ │ ┌─────▼─────┐ │ │ │ results │ │ │ └───────────┘

ah interesting - so you want to use the result of one of those two build tasks in the last task? it does sound like this proposal should help with the consolidation task (im wondering if being able to make sub pipelines might help you too - but i think you'd still need the consolidation task + @jerop )- i think we've also had feature requests for better support for the specific scenario you're describing as well (e.g. choose which of several tasks to run vs. just gating them) but we've never pursued it

tekton-robot · 2021-06-07T15:38:15Z

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.

Adding TEP with problem statement to evaluate the need for task results without results.

pritidesai · 2021-06-11T18:38:35Z

The recent comments were raising concerns over the use cases. I have limited the content of this PR to first evaluate the use cases and problem statement. Once we agree on the problem statement, I will add the proposal section back.

/remove-lifecycle stale

bobcatfish

Thanks for adding the use cases! I have a tweak I'd like to propose for one of the use cases but overall lgtm :)

/approve

bobcatfish · 2021-06-22T14:21:26Z

teps/0048-task-results-without-results.md

+
+  Further, extending the same use case, when someone approves the PR, the `approver` would be set to an appropriate
+  name. At the same time, set the task result `approver` to **None** in case the `manual-approval` task is skipped and
+  the `approver` is not initialized. It is still possible to send a notification that no one approved the PR.


hmm interesting - in TEP-0059 we were assuming that the user would WANT to skip the manual approval entirely - including the notification. for example, if this was running against a pull request, would you want to send a slack notification every time the PR is updated? maybe but probably not (which is what i understand to be the premise of the use case in TEP-59)

maybe we can tweak the example a bit to make it work here - in this case, where we're running the pipeline on a PR, maybe we need to start a temporary cluster to deploy to? (since we don't want to deploy to prod)

lint unit-tests | | v v report-linter-output integration-tests | v manual-approval | | v (approver) (if pull-request) build-image | set-up-cluster | v | | slack-msg v | (cluster ip, etc.). | | v --------------> deploy-image

In this example, when we run the pipeline for a pull request, we want to setup a cluster and pass the info about that cluster to deploy-image, but when we want to deploy to prod, we want to use params that are passed in with the prod cluster

(this is a bit flawed b/c you probably need more than just the ip and a string result might not be the best way to pass that - but maybe we could imagine in a world with dict params + results this makes a bit more sense?)

so we'd need to be able to express that when set-up-cluster is skipped, instead of trying to use it's results and skipping deploy-image (which depends on set-up-cluster), we use the params

(or we could remove it, the next 2 use cases have it covered!)

this is a useful use case, where the default results are variables that users would need to pass in as parameters

Right, you have precisely captured a tweak here with the use case from TEP-0059.

jerop · 2021-06-28T16:15:19Z

/remove-lifecycle stale

ScrapCodes · 2021-07-09T11:43:24Z

teps/0048-task-results-without-results.md

+    - name: APP_IMAGE
+      value: $(tasks.propagate-image-name.results.image)
+```
+


Is it correct to think, another possible use case can be, for resuming failed pipelines.

The tasks that ran fine can be somehow disabled (either with some future TEP or when expression), and their results pre-populated, while copying and creating a new Pipeline/PipelineRun in order to retry/resume.

that's an interesting use case for this @ScrapCodes 🤔

my feeling is that in the resuming a pipeline case, usually youd want to use the result value produced by the previous run, and not the default value - tho maybe sometimes you would?

for example, say you were trying to do a build + deploy:

spec: tasks: - name: build-image taskRef: name: build-image results: - name: image-name - name: deploy-image params: - name: image-name value: "$(tasks.build-image.results.image-name)" # using the image that was built by build-image taskRef: name: deploy-image

Maybe deploy-image failed, and you want to run the pipeline again, but you don't want to have to build again, you probably want to use the value of tasks.build-image.results.image-name from the previous run.

If you used the functionality proposed here, you'd be using some default value for the image-name instead of the value that was just built. For example, imagining a syntax for specifying a default to use:

spec: tasks: - name: build-image taskRef: name: build-image results: - name: image-name - name: deploy-image params: - name: image-name value: "$(tasks.build-image.results.image-name?my-website:v0.4.0)" taskRef: name: deploy-image

Let's say this built an image my-website:v0.7.0, but deploy-image failed. If you wanted to re-run, i.e. partially run the pipeline with build-image disabled, I'm guessing you'd want to pass my-website:v0.7.0 (the one you just built) and not use the default my-website:v0.4.0

Probably there are cases for both tho!

jerop

compelling problem statement, thanks @pritidesai 😁

jerop · 2021-07-27T18:25:22Z

teps/0048-task-results-without-results.md

+This example shows that `B` is guarded with task results from `A` where `A` was skipped but is it really a possible
+scenario? When this `pipeline` says continue executing `B` even though `A` was skipped, why would `B` be guarded with a
+task result from `A`?
+


this is interesting -- just wondering how it'd look like if the default was a variable

would it be $(tasks.foo.results.bar?$(params.someDefault)) 🙃 -- maybe $(tasks.foo.results.bar?params.someDefault) is better?

but then how would this look like if we add support for array results proposed in #477?

(back to focusing on the problem statement only lol)

jerop · 2021-07-27T18:31:08Z

teps/0048-task-results-without-results.md

+
+  Further, extending the same use case, when someone approves the PR, the `approver` would be set to an appropriate
+  name. At the same time, set the task result `approver` to **None** in case the `manual-approval` task is skipped and
+  the `approver` is not initialized. It is still possible to send a notification that no one approved the PR.


this is a useful use case, where the default results are variables that users would need to pass in as parameters

afrittoli

Nice, looking forward to this! Thank you @pritidesai @jerop
/approve

tekton-robot · 2021-08-02T13:17:42Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, bobcatfish, jerop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~teps/OWNERS~~ [afrittoli,bobcatfish,jerop]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

pritidesai · 2021-08-02T16:12:16Z

As per the new policy, we have approvals from all the assignees, adding lgtm during the API WG
/lgtm

tekton-robot · 2021-08-02T16:12:17Z

@pritidesai: you cannot LGTM your own PR.

In response to this:

As per the new policy, we have approvals from all the assignees, adding lgtm during the API WG
/lgtm

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.

jerop · 2021-08-02T16:13:38Z

adding lgtm because @pritidesai (facilitator in API WG) can't lgtm her own pr

/lgtm

tekton-robot requested review from a-roberts and ncskier October 22, 2020 07:38

tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 22, 2020

pritidesai force-pushed the task-results branch 2 times, most recently from 0472685 to 18dd2e0 Compare October 22, 2020 07:42

jerop reviewed Oct 26, 2020

View reviewed changes

teps/0028-task-results-without-results.md Outdated Show resolved Hide resolved

pritidesai mentioned this pull request Oct 26, 2020

Failed TaskRuns should still report results tektoncd/pipeline#3439

Closed

bobcatfish reviewed Oct 26, 2020

View reviewed changes

GregDritschler reviewed Oct 26, 2020

View reviewed changes

bobcatfish mentioned this pull request Nov 4, 2020

Fix bug where PipelineRun emits task results that were never produced tektoncd/pipeline#3472

Merged

4 tasks

afrittoli changed the title ~~adding tep for task results without results~~ TEP-0028 adding tep for task results without results Nov 16, 2020

afrittoli reviewed Nov 19, 2020

View reviewed changes

teps/0028-task-results-without-results.md Outdated Show resolved Hide resolved

afrittoli reviewed Nov 19, 2020

View reviewed changes

vdemeester added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Nov 23, 2020

jmcshane reviewed Dec 31, 2020

View reviewed changes

pritidesai force-pushed the task-results branch 2 times, most recently from 9bd8a3c to 1cac70b Compare January 23, 2021 01:05

tekton-robot assigned jerop Jan 25, 2021

chmouel mentioned this pull request Jan 26, 2021

Is there any way to tell whether any of the finally tasks failed? tektoncd/pipeline#3715

Closed

tekton-robot assigned bobcatfish Feb 2, 2021

pritidesai force-pushed the task-results branch 2 times, most recently from 5d24357 to 3340701 Compare February 2, 2021 22:39

Base automatically changed from master to main February 3, 2021 16:34

vdemeester reviewed Feb 5, 2021

View reviewed changes

afrittoli mentioned this pull request Feb 8, 2021

Publish results when task and pipeline runs fail tektoncd/pipeline#3749

Open

bobcatfish reviewed Feb 18, 2021

View reviewed changes

tekton-robot assigned afrittoli Feb 22, 2021

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 23, 2021

jromero mentioned this pull request Feb 26, 2021

Add APP_IMAGE_DIGEST result to pipeline/buildpacks buildpacks/tekton-integration#23

Open

jromero reviewed Mar 5, 2021

View reviewed changes

afrittoli mentioned this pull request Mar 18, 2021

Catlin: Report logs back to the PR after execution tektoncd/plumbing#758

Merged

2 tasks

tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 7, 2021

adding tep for task results without results

a936fd3

Adding TEP with problem statement to evaluate the need for task results without results.

pritidesai force-pushed the task-results branch from 3340701 to a936fd3 Compare June 11, 2021 18:34

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 11, 2021

pritidesai changed the title ~~TEP-0028 adding tep for task results without results~~ TEP-0048: task results without results - problem statement Jun 11, 2021

bobcatfish reviewed Jun 22, 2021

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 22, 2021

tekton-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 28, 2021

ScrapCodes reviewed Jul 9, 2021

View reviewed changes

bobcatfish mentioned this pull request Jul 23, 2021

TEP-0059: Skipping Strategies tektoncd/pipeline#4085

Merged

5 tasks

jerop approved these changes Jul 27, 2021

View reviewed changes

afrittoli reviewed Aug 2, 2021

View reviewed changes

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Aug 2, 2021

tekton-robot merged commit e9c4bf7 into tektoncd:main Aug 2, 2021

bobcatfish mentioned this pull request Mar 25, 2022

[TEP-0075, 0076] Make array and object support implementable 👷‍♀️ #661

Merged

jerop mentioned this pull request Feb 13, 2023

[TEP-0048] Task Results without Results #954

Open


		### Non-Goals

		This proposal is not offering a solution without any use case.


		### Goals

		Identify a set of use cases for `finally` and `continueAfterSkip` without task results and design a common solution


		## Proposal

		Enable `pipeline` author to specify a default value for a `task result` in case of a missing result. Pipeline author

x param type	result default	multiply execution
mandatory	supplied	executed
mandatory	not supplied	skipped
optional	supplied	executed
optional	not supplied	executed


		#### Story 2

		Need user story for `finally` task with optional `param` referring to a task result.

TEP-0048: task results without results - problem statement #240

TEP-0048: task results without results - problem statement #240

Conversation

pritidesai commented Oct 22, 2020 • edited Loading

bobcatfish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrittoli left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrittoli Nov 19, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrittoli commented Nov 23, 2020

Choose a reason for hiding this comment

bobcatfish commented Jan 25, 2021

afrittoli commented Feb 1, 2021

bobcatfish commented Feb 2, 2021

vdemeester left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bobcatfish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrittoli commented Feb 22, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tekton-robot commented Jun 7, 2021

pritidesai commented Jun 11, 2021 • edited Loading

bobcatfish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerop commented Jun 28, 2021

ScrapCodes Jul 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerop left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrittoli left a comment

Choose a reason for hiding this comment

tekton-robot commented Aug 2, 2021

pritidesai commented Aug 2, 2021

tekton-robot commented Aug 2, 2021

jerop commented Aug 2, 2021 • edited Loading

pritidesai commented Oct 22, 2020 •

edited

Loading

afrittoli Nov 19, 2020 •

edited

Loading

pritidesai commented Jun 11, 2021 •

edited

Loading

ScrapCodes Jul 9, 2021 •

edited

Loading

jerop commented Aug 2, 2021 •

edited

Loading