Skip to content
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

Adding TEP for task results in final tasks #153

Merged
merged 1 commit into from
Jul 22, 2020

Conversation

pritidesai
Copy link
Member

Proposal for enabling final tasks to get value from non-final tasks.

Design Doc

Issue #2557

@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 18, 2020
Copy link
Contributor

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I have a bit of feedback about a user story and an example but overall I'm very excited and I really like the proposal :D

teps/draft-20200716-task-results-in-final-tasks.md Outdated Show resolved Hide resolved

* No API changes.

* Finally contract does not break and all final tasks are attempted.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 this was a great call, thanks for thinking of this approach @pritidesai !

teps/draft-20200716-task-results-in-final-tasks.md Outdated Show resolved Hide resolved
@pritidesai pritidesai force-pushed the tep-final-task-results branch 3 times, most recently from e19f6dd to 90b4a0b Compare July 20, 2020 23:54
@pritidesai
Copy link
Member Author

@bobcatfish I have addressed your comments and also added a very high level workflow to help understand it better.

What are the next steps in terms of changing the filename or status? 🤔

@pritidesai
Copy link
Member Author

pritidesai commented Jul 21, 2020

Also, two things I came across while working on this PR regarding the TEP template in general:

  1. Links to GitHub issue and/or design doc in Google drive - should we create a separate section called References or add a placeholder to insert the GitHub issue? or something similar?

  2. Inserting images, might be a good idea to designate a directory called /teps/images/ and ask TEP authors to add files in that directory by following a specific naming convention.

@vdemeester @bobcatfish Thoughts?

@vdemeester
Copy link
Member

1. Links to GitHub issue and/or design doc in Google drive - should we create a separate section called `References` or add a placeholder to insert the GitHub issue? or something similar?

Good point, I think we can definitely have a References header to help referering to anything we may want to refer (other TEPs, design docs, issues, …)

2. Inserting images, might be a good idea to designate a directory called `/teps/images/` and  ask `TEP` authors to add files in that directory by following a specific naming convention.

Either that or /teps/TEP-0004/ for TEP-0004 resources (images, …) ? Not sure which one I prefer 😝

@vdemeester @bobcatfish Thoughts?

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few small comments
/lgtm

Comment on lines 75 to 76
However if the `Task` being attempted has a default value for that parameter, it can still run,
using the default when result is not available.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would highly a bit more the default part. In a few sentences what we are proposing is : You can refer to results from tasks, and provide a default value if those results did not get populated. Any non-populated results that do not have a default will make the finally task fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(oh it's on the "default" params, I see)

```

**Note:** Today final tasks are executed all in parallel and can not depend on any other `Task` in the `Pipeline`.
With adding support for `Task` `Results`, we are introducing dependencies to finally `Tasks` but that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I understand this (nor if it should be there). What we are saying is "now finally tasks depends on tasks" ? that was implicitly the case already (from the user perpective) as the finally task will wait for all the "normal" task to complete (success or failure).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we are saying is "now finally tasks depends on tasks" ? that was implicitly the case already (from the user perpective) as the finally task will wait for all the "normal" task to complete (success or failure).

Finally tasks did not have any implicit/explicit dependency on any other task. The scheduling algorithm sends final tasks to execute after all normal/DAG tasks are completed. Now, with task results, implicit dependency is being introduced. There is no impact on scheduling yet, final tasks still scheduled after all DAG. But worth calling out now and will easier to understand what happens when we add support for task results from other final tasks, runAfter in final tasks, from in final tasks, etc

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 21, 2020
@bobcatfish
Copy link
Contributor

Good point, I think we can definitely have a References header to help referering to anything we may want to refer (other TEPs, design docs, issues, …)

great idea!!

  1. Inserting images, might be a good idea to designate a directory called /teps/images/ and ask TEP authors to add files in that directory by following a specific naming convention.
    Either that or /teps/TEP-0004/ for TEP-0004 resources (images, …) ? Not sure which one I prefer 😝

i have no strong opinion! slight inclination toward /teps/images/ to keep it simple

@bobcatfish
Copy link
Contributor

What are the next steps in terms of changing the filename or status? 🤔

I'm thinking we can at least merge as "proposed" asap (correct me if I'm wrong @vdemeester ) with the final filename, and then open another PR to change that to "implementable" and continue discussing

Copy link
Contributor

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor feedback from me, but nothing that would stop us from merging with proposed status!


**A.**

```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain the context of this workflow a bit more? e.g. " Param Validation " i'm not sure if you mean, params to the finally tasks? params for all tasks?

(also im confused how we can validate the params before we apply results from dependent tasks?)

Copy link
Member Author

@pritidesai pritidesai Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this context, "Param validation" resolves params and run syntax check on params to all final tasks:

(1) check if parameter name is unique
(2) type of the default value matches with its type
(3) param with task results has valid result reference i.e. $(tasks.results.taskName.param)
(4) resolve parameter mapping and apply values from PipelineRun or Pipeline

"Validate and Apply results from Dependent Tasks" actually resolves the task result from dependent tasks and applies those values to params in the final tasks.

In general, the same workflow is executed for non-final tasks too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

k i think this is a bit more clear to me


* This proposal is extensible with a param validation proposal using Schema -
[#1393](https://github.com/tektoncd/pipeline/issues/1393#issuecomment-558833526) by reading default from
`Task` specification.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to remove this reference to schema as well? maybe this is a discussion for somewhere else, but this is how i would see this feature interacting with schema:

  • Param defaults should always pass their own schema; if a task declares a default that does not pass it's schema, the Task creation should fail
  • If we one day add Result defaults, when a Task fails, the default of the result could be used as the Result of that Task. If a Task wants to use that result as the value for one if its own params, then the Task validation will evaluate that value; if the default is invalid, the validation will fail, if it is valid, the Task can continue

Copy link
Member Author

@pritidesai pritidesai Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure @bobcatfish, shall I drop the whole bullet point along with the example? or just the schema reference?

Copy link
Member Author

@pritidesai pritidesai Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

never mind, I just dropped the reference and have the example as is.


> `PipelineRun` reads parameter defaults from `Pipeline` specification but in case of
parameters associated with `Task` `Results`, the default values will be used from the `Task` since
`Pipeline` has no direct mapping between `Pipeline` parameter and `Task` parameter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the example below meant to demonstrate that even if boskos-acquire fails, boskos-release will still run because it has a default for the param? if so i think we might want to say that explicitly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, added it explicitly 😄

@vdemeester
Copy link
Member

So we should "assign" a number to the TEP before merging as proposed (so that we rename it 0005-…), that would be the only requirement :)
Feels like it should be 0004 as I see this one getting merged before #147 for example 🙃

@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label Jul 21, 2020
Proposal for enabling final tasks to get value from non-final
tasks.
@pritidesai
Copy link
Member Author

pritidesai commented Jul 21, 2020

@bobcatfish @vdemeester I have renamed the file to 0004-task-results-in-final-tasks.md, made two changes:

  1. Dropped the reference to GitHub issue with param validation schema
  2. Added explicitly "task is executed with default value if dependency fails and no task result produced" under "Advantages" section.

Ready to review again 🙏

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 22, 2020
@bobcatfish
Copy link
Contributor

Let's go for it! Then we can open a PR to get it to implementable :D

/approve

@tekton-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish

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:

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

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 22, 2020
@tekton-robot tekton-robot merged commit 0919d59 into tektoncd:master Jul 22, 2020
dlorenc pushed a commit to dlorenc/community that referenced this pull request Oct 27, 2022
…stamp (tektoncd#153)

* Disallow requiring the branch to be up to date for rekor-monitor/timestamp

This was a bit of a nuisance since it required a rebase constantly.

Also turned off merge commits for rekor-monitor.

Also turned off merge commits for fulcio, and enforced admins too.

Signed-off-by: Hayden B <hblauzvern@google.com>

* add dismissStaleReviews

Signed-off-by: cpanato <ctadeu@gmail.com>

Signed-off-by: Hayden B <hblauzvern@google.com>
Signed-off-by: cpanato <ctadeu@gmail.com>
Co-authored-by: cpanato <ctadeu@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants