-
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
Adding support for taskSpec with pipelineSpec #1554
Conversation
The following is the coverage report on pkg/.
|
/assign @vdemeester |
@vdemeester please let me know if there are any changes needed ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @pritidesai ...A few small nits. Otherwise looks good!
Also would you mind updating the Release Notes section of the PR description?
31436ef
to
7b16783
Compare
The following is the coverage report on pkg/.
|
/retest |
Added same example to be clear and adding more value in Release Notes, would that be ok? |
7b16783
to
806a7b3
Compare
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-build-tests |
/retest |
806a7b3
to
29aa113
Compare
The following is the coverage report on pkg/.
|
29aa113
to
fffb582
Compare
The following is the coverage report on pkg/.
|
fffb582
to
e12ba8d
Compare
The following is the coverage report on pkg/.
|
Thanks @dibyom for the review, I have addressed all of your feedback/comments, its building as well (after multiple tries :( ) ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/cc @bobcatfish
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this, very useful.
I have a couple of minor comments / questions - let me know what you think.
command: | ||
- echo | ||
args: | ||
- "$(inputs.params.MESSAGE)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would using $(params.GREETINGS)
work here?
I find that one of the advantages of embedding is a more concise YAML. Since the task definition is embedded, it's not reusable (by definition), so there is little value in having input parameters in the task, if we can consume directly the pipeline parameters (and resources).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @afrittoli $(params.GREETINGS)
will not work here as task is aware of only one input param named MESSAGE
, here in this example, GREETINGS
's value is assigned to task's input param MESSAGE
. If we replace line 26 with $(params.GREETINGS)
, pod will have a output of:
$(params.GREETINGS)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it should work or not though… My gut feeling as a user would be that I can use pipeline params in the embedded TaskSpec
(which is not the case with this PR), right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if we wanted that we'd need syntax like pipeline.params.FOO
, right? Since both the pipeline and the task could have a param called FOO and they might have different intended meanings. So $(params.FOO)
would be a bit confusing (to Tekton controller, but also to users). Or we could assume that task params always "win" if there's a same named param in both pipeline and task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if we wanted that we'd need syntax like
pipeline.params.FOO
, right? Since both the pipeline and the task could have a param called FOO and they might have different intended meanings. So$(params.FOO)
would be a bit confusing (to Tekton controller, but also to users). Or we could assume that task params always "win" if there's a same named param in both pipeline and task.
Not entirely sure to be honest. I think the main question is, should the embedded TaskSpec
in a PipelineSpec
have the exact same feature fields as a normal TaskSpec
? Should we have Params
at all in the embedded TaskSpec
at all ? (from a user perspective, we don't really need to care about the implementation).
As a user, if I use an embedded TaskSpec
, I kinda expect that the PipelineSpec.params
can be used "as is" in the rest of the struct, which is not the case with the current state. I'm wondering if this is what others would expect or not 👼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh i see. Yeah I like that. Pipeline has params but embedded task doesnt need them and just defers to the pipeline.
Implementation of that could be quite simple - embedded task spec is "hydrated" with a copy of the params from the pipeline before the taskrun is started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added couple of more variations just for users to understand it until we change the existing behavior.
Thanks @afrittoli, I have addressed your comments and questions. Let me know what you think. |
e12ba8d
to
4f39949
Compare
NIT: In case you have to respin respin this for the test failures, it would be nice to document that the embedded task cannot refer do the PipelineRun parameters directly. we can do that as follow up too. |
4f39949
to
f2628a7
Compare
thanks @afrittoli hopefully have fixed the build failure, had not pulled latest changes from master 😢 |
The following is the coverage report on pkg/.
|
/retest |
Its ready for review again 🤔 |
f2628a7
to
22adf79
Compare
The following is the coverage report on pkg/.
|
Thank you for the updates! Would you mind filing an issue about supporting access to pipeline params directly in the task spec, so we don't forget about it? I can also create it if you prefer so. |
Hey @afrittoli just opened an issue here #1879, please correct it if my interpretation/understanding is off, also sorry for delay, not feeling well past few days, my twin boys passed something to me that they have been sick with 😢 |
22adf79
to
d1f16f6
Compare
/test pull-tekton-pipeline-build-tests |
Now, this is possible: apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: pipelinerun-echo-greetings spec: pipelineSpec: tasks: - name: echo-good-morning taskSpec:
d1f16f6
to
cd82e3c
Compare
The following is the coverage report on pkg/.
|
@afrittoli its ready for review again, had to resolve conflicts 😭 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍
(sorry for the conflicts, I may have a role in it 😛)
/meow
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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester 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 |
Thank you for this! |
Changes
Now, this is possible:
Closes #872
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Allow embedding task specification with
taskSpec
underpipelineSpec
such as: