-
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
Resolve all PipelineResources first before continuing #1353
Conversation
@pritidesai if this causes any conflicts with #1324 I'm happy to deal with the conflicts! But also maybe #1324 can get merged first and then I can deal with them in this PR :D |
cae91a6
to
511d009
Compare
The following is the coverage report on pkg/.
|
511d009
to
43b3ef1
Compare
The following is the coverage report on pkg/.
|
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
/hold
Am adding the hold just to make sure that the merge doesn't happen prior to #1324
// getResource will return an instance of a PipelineResource to use for r, either by getting it with getter or by | ||
// instantiating it from the embedded spec. | ||
func getResource(r *v1alpha1.TaskResourceBinding, getter GetResource) (*v1alpha1.PipelineResource, error) { | ||
// Check both resource ref or resource Spec are not present. Taskrun webhook should catch this in validation error. |
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.
Very minor nit (and I see that this func has just been moved from another place, so it's totally not required to fix this now) but the block of code below this is pretty self-explanatory. This comment probably isn't needed?
Spec: *r.ResourceSpec, | ||
}, nil | ||
} | ||
return nil, xerrors.New("Neither ResourseRef not ResourceSpec is defined") |
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.
not
-> nor
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
/meow boxes
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: bobcatfish, 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 |
43b3ef1
to
a4ef169
Compare
/lgtm |
As part of tektoncd#1184 I need to call `GetSetup` on all PipelineResources early on in PipelineRun execution. Since PipelineRuns declare all their resource up front, I wanted to be able to resolve all of them at once, then call `GetSetup` on all of them. Also, as Pipelines got more complex (we added Conditions) it turned out we were retrieving the resources in a few different places. Also in tektoncd#1324 @pritidesai is making it so that these Resources can be provided by spec. By resolving all of this up front at once, we can simplify the logic later on. And you can see in this commit that we are able to reduce the responsibilities of ResolvePipelineRun a bit too!
a4ef169
to
37d5327
Compare
The following is the coverage report on pkg/.
|
/hold still re-doing some things post #1324 |
The following is the coverage report on pkg/.
|
10b6f5b
to
ef5c635
Compare
The following is the coverage report on pkg/.
|
Okay! Now rebased on #1324, PTAL @pritidesai @sbwsg @vdemeester (note @vdemeester note the potential impact on the client usage for the CLI - maybe dashboard too? - I can avoid this by instead duplicating the logic to determine if a binding is a Ref or a Spec, but once we get to #1284 we'll probably remove "path" from the TaskRun binding so it's gonna change at that point anyway. Lemme know if you feel strongly and plz tag anyone else you think would be interested. |
The following is the coverage report on pkg/.
|
/lgtm This is great and works like a charm, thanks @bobcatfish for the simplification, the code is much more readable now ❤️ |
The API doesn't change, so this is just a matter of bump the dependency. But both an old client or new client will still work against the API, so no need to duplicate things 😉 |
/lgtm |
/hold cancel Thanks for the feedback all!! |
why hello stronger linting, don't mind if i do
|
In tektoncd#1324 we updated PipelineRuns to allow for embedding ResourceSpecs in PipelineRuns. This commit makes it so that the logic for resolving (i.e. deciding if PipelineResources are specified by Spec or Ref) is shared by PipelineRuns + TaskRuns. This is done by making it so that the "binding" uses the same type underneath. The only reason they can't be the exact same type is that TaskRuns additionally need the "path" attribute, which is actually only used for PVC copying, which will be removed in tektoncd#1284, and then we should be able to remove paths entirely and the type can be the same. Also added some additional comments around the use of `SelfLink`, and made sure it was well covered in the reconciler test.
ef5c635
to
aa4fb0a
Compare
The following is the coverage report on pkg/.
|
/lgtm |
Changes
Pre #1324
As part of #1184 I need to call
GetSetup
on all PipelineResourcesearly on in PipelineRun execution. Since PipelineRuns declare all their
resource up front, I wanted to be able to resolve all of them at once,
then call
GetSetup
on all of them. Also, as Pipelines got more complex(we added Conditions) it turned out we were retrieving the resources in
a few different places. Also in #1324 @pritidesai is making it so that
these Resources can be provided by spec. By resolving all of this up
front at once, we can simplify the logic later on. And you can see in
this commit that we are able to reduce the responsibilities of
ResolvePipelineRun a bit too!
Post #1324
In #1324 we updated PipelineRuns to allow for embedding ResourceSpecs in
PipelineRuns. This commit makes it so that the logic for resolving (i.e.
deciding if PipelineResources are specified by Spec or Ref) is shared by
PipelineRuns + TaskRuns. This is done by making it so that the "binding"
uses the same type underneath. The only reason they can't be the exact
same type is that TaskRuns additionally need the "path" attribute, which
is actually only used for PVC copying, which will be removed in #1284,
and then we should be able to remove paths entirely and the type can be
the same.
Also added some additional comments around the use of
SelfLink
, andmade sure it was well covered in the reconciler test.
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