-
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
Add pipelineRef remote resolution #4596
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/hold Holding for more documentation + more reconciler tests + better coverage numbers. |
The following is the coverage report on the affected files.
|
Adding a short copy/pastable PipelineRun that can be used for manual testing: apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: reqpr
spec:
params:
- name: name
value: Scott
pipelineRef:
resolver: git
resource:
- name: url
value: https://github.com/sbwsg/catalog.git
- name: commit
value: f0629ad5f9046bb8ff853f5303a5158e6dba409c
- name: path
value: /pipeline/simple/0.1/simple.yaml |
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-integration-tests |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
case errors.Is(err, resolution.ErrorRequestInProgress): | ||
message := fmt.Sprintf("PipelineRun %s/%s awaiting remote resource", pr.Namespace, pr.Name) | ||
pr.Status.MarkRunning(ReasonResolvingPipelineRef, message) | ||
return nil |
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.
It seems like if a reconcile loop is triggered when the ref is being resolved, it'll stop reconciling, but what triggers another reconcile loop when the ref is done being resolved? It seems like (based on the tests) that the ref crd will be updated, and this will trigger another reconcile loop, but maybe worth adding a comment?
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.
Yeah you're totally right about how this works. It's the event handler added to the ResourceRequest informer in pkg/reconciler/pipelinerun/controller.go
that binds PipelineRun's reconciler to updates on ResourceRequests.
I am not totally sure this is the right spot for a comment on that specific mechanism though, since it's pretty far removed from it. Commenting the AddEventHandler(
call in pkg/reconciler/pipelinerun/controller.go
in turn feels like it would be restating what the code there already says.
What info and/or location in the code would be most helpful to document this d'you think?
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 think what is specifically confusing is that the remote resolution is returning an error, but the pipelinerun resolution is not returning an error. For taskruns contained in pipelineruns, if a taskrun is still running, we treat this as status "pending", not an error. It would make more sense to me to handle a ref that is still resolving the same way. would it be possible to treat the ResourceRequest as "pending" rather than an 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.
Ah I see, so if we updated the signature of resources.GetPipelineData
to something like this:
pipelineMeta, pipelineSpec, pending, err := resources.GetPipelineData(ctx, pr, getPipelineFunc)
switch {
case pending:
// The code here to mark the PR as pending
case err != nil:
// The code here to fail the PipelineRun
default:
// The code to store the pipeline meta and spec on pr.status
}
Does that read clearer than the sentinel check we have here atm?
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.
After discussing offline and spending a bit of time trying to rejig this bit of the code I think I'm going to leave it as-is for the time being.
There's scope here for a tidier interface between the reconcilers and pipelineref resolution but the codebase is in a bit of an in-between state because we have resolution logic in (a) the reconcilers themselves (b) the resources subpackage which abstracts some resolution mechanics and (c) the remote package which hides away the built-in OCI bundles resolution (and now the new remoteresolution functionality).
A holistic change to the way this all works makes sense, and is def something we can look at in another pr, but for this one I'm trying to avoid changing how tekton's existing resolution mechanics function to limit blast radius of the new code.
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.
SGTM! Would you be able to create an issue or something to describe a refactoring that would make more sense?
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.
We do have an issue around this, #3305, so I've added a comment describing the remaining work to do here: #3305 (comment)
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.
sounds good, thanks!
@@ -85,6 +90,10 @@ func NewController(opts *pipeline.Options, clock clock.Clock) func(context.Conte | |||
FilterFunc: controller.FilterController(&v1beta1.PipelineRun{}), | |||
Handler: controller.HandleAll(impl.EnqueueControllerOf), | |||
}) | |||
resourceRequestInformer.Informer().AddEventHandler(cache.FilteringResourceEventHandler{ |
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.
does this require someone to have the resourcerequest CRD defined in their cluster? (genuinely asking)
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.
Yes you're absolutely right, and this is why the integration tests are all failing badly.
The only workaround I can think of right now is to put this initialization behind an environment variable that the user must explicitly enable.
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.
OK, unfortunately it doesn't look like I can optionally start informers like that, I'll have to think of something else.
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 saw the slack conversation you opened on pipeline-dev; I agree with Matt Moor that it would be OK to import the ResourceRequest CRD as part of the Tekton pipelines config.
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've brought the CRD over into pipelines. One unfortunate downside is that this means the CRD is duplicated both in resolution and here. I tried vendoring the CRD yaml in resolution but go mod
doesn't pull anything except go code into pipelines.
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.
ack -- that's too bad but it doesn't sound like there's a good way around this duplication.
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've removed the CRD from resolution. Now the definition in Pipelines is the only one and Tekton Resolution will lean on that rather than the other way round.
@@ -71,18 +71,25 @@ func (ref *TaskRef) validateInTreeRef(ctx context.Context) (errs *apis.FieldErro | |||
// valid remote resource reference or a valid in-tree resource reference, | |||
// but not both. | |||
func (ref *TaskRef) validateAlphaRef(ctx context.Context) (errs *apis.FieldError) { | |||
switch { | |||
case ref.Resolver == "" && ref.Resource != nil: | |||
hasResolver := ref.Resolver != "" |
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.
some readability nits: maybe also define hasName
and hasBundle
, and I think some of the if statements might actually be more readable if they were nested (esp the last two).
Also, it looks like there are two new branches here (resource + name and resource + bundle), seems worth adding test cases for them? The changes to this file could be split into a separate pr if 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.
I've had a go at tackling these readability nits and added a unit test, should be ready for another look!
prt := newPipelineRunTest(d, t) | ||
defer prt.Cancel() | ||
|
||
pipelinerun, _ := prt.reconcileRun("default", "pr", nil, false) |
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.
nit: can you comment these params inline here and below, e.g. reconcileRun("default", "pr", /* wantEvents=*/ nil, /*permanentErr */ = false)
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 named variables for these, cheers!
script: | | ||
echo "hello world!" | ||
`) | ||
resreq.Status.ResourceRequestStatusFields.Data = base64.StdEncoding.Strict().EncodeToString(pipelineBytes) |
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.
possibly out of scope for this PR, but this might benefit from some testing helper functions for mocking returned data.
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.
Good point, this isn't something I've tackled as part of this PR but I am also starting to think about how the resolution
package could provide test helpers / mocks for this so that pipelines doesn't have to own them.
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.
consider adding a TODO comment here to move out of this test file
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 created an issue in resolution
to capture this: tektoncd/resolution#10
@@ -107,3 +120,19 @@ func (l *LocalPipelineRefResolver) GetPipeline(ctx context.Context, name string) | |||
} | |||
return l.Tektonclient.TektonV1beta1().Pipelines(l.Namespace).Get(ctx, name, metav1.GetOptions{}) | |||
} | |||
|
|||
func readRuntimeObjectAsPipeline(ctx context.Context, obj runtime.Object) (v1beta1.PipelineObject, 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.
can you please add a comment for this function?
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 a comment.
@@ -291,6 +293,46 @@ func TestGetPipelineFuncSpecAlreadyFetched(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestGetPipelineFunc_RemoteResolution(t *testing.T) { |
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.
might also be worth adding a test case where the bytes returned are invalid
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 a UT for invalid bytes.
@@ -0,0 +1,64 @@ | |||
package resolution |
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.
missing a copyright
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.
Good catch, cheers, fixed!
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-alpha-integration-tests |
Alpha integration failed first on |
/test pull-tekton-pipeline-alpha-integration-tests |
/test pull-tekton-pipeline-alpha-integration-tests |
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-alpha-integration-tests /test pull-tekton-pipeline-integration-tests |
workspace-in-sidecar and another example failed. neither related to the PR. /test pull-tekton-pipeline-alpha-integration-tests |
@tektoncd/core-maintainers Feedback from Pipelines WG has been addressed and this PR is ready for another look. Cheers! |
/lgtm |
Rebased on main. |
The following is the coverage report on the affected files.
|
config/300-resolutionrequest.yaml
Outdated
name: resolutionrequests.resolution.tekton.dev | ||
labels: | ||
resolution.tekton.dev/release: devel | ||
knative.dev/crd-install: "true" |
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.
what does this label do?
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.
Ah, good question :S
I think it's used to filter which resources to install when a user executes kubectl apply
. This isn't used by any of the other pipeline crds so I'll remove it. Cheers!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom 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 |
Prior to this commit the API fields for remote resolution were just stubs with no functionality. This commit adds support for resolving pipelineRefs from public git repos using the tektoncd/resolution project. This feature is in alpha and relies on a new CRD called a ResourceRequest.
The following is the coverage report on the affected files.
|
Updated resolution to be based on latest knative + go1.17. Should be ready for one final look + (hopefully 🤞) lgtm! |
Also we have a first draft of a Bundles resolver: https://github.com/tektoncd/resolution/tree/main/bundleresolver |
Workspace-in-sidecar failed; known flake /test pull-tekton-pipeline-alpha-integration-tests |
TestPipelineTaskTimeout failed with
I can't reproduce this locally so let's see if it repeats. /test pull-tekton-pipeline-alpha-integration-tests |
/lgtm |
Followup to tektoncd#4596, needed for tektoncd#4710. remote resolution, both in explicitly created `TaskRun`s and in `PipelineRun`s' `PipelineTask`s, from public git repositories using tektoncd/resolution. This is still in alpha. Signed-off-by: Andrew Bayer <[email protected]>
Followup to tektoncd#4596, needed for tektoncd#4710. remote resolution, both in explicitly created `TaskRun`s and in `PipelineRun`s' `PipelineTask`s, from public git repositories using tektoncd/resolution. This is still in alpha. Signed-off-by: Andrew Bayer <[email protected]>
Followup to tektoncd#4596, needed for tektoncd#4710. Enables remote resolution of `Task`s, both in explicitly created `TaskRun`s and in `PipelineRun`s' `PipelineTask`s, from public git repositories using tektoncd/resolution. Also modifies `resolution.Resolver` to take both owner and optional name/namespace. This is needed because we don't necessarily have a `TaskRun` yet when calling `GetTaskFunc` in the `PipelineRun` reconciler, but still need to ensure that we only make one remote resolution request for a `PipelineTask` via the `PipelineRun` and `TaskRun` reconcilers. Therefore, we must have the same deterministically-generated resolution request name in both places, using the predictable eventual `TaskRun` name and namespace. We also want to make sure that the created `ResolutionRequest` has the appropriate owner reference, hence still passing a `kmeta.OwnerRefable` to `NewResolver` as well as the name and namespace. This is still in alpha. Signed-off-by: Andrew Bayer <[email protected]>
Followup to #4596, needed for #4710. Enables remote resolution of `Task`s, both in explicitly created `TaskRun`s and in `PipelineRun`s' `PipelineTask`s, from public git repositories using tektoncd/resolution. Also modifies `resolution.Resolver` to take both owner and optional name/namespace. This is needed because we don't necessarily have a `TaskRun` yet when calling `GetTaskFunc` in the `PipelineRun` reconciler, but still need to ensure that we only make one remote resolution request for a `PipelineTask` via the `PipelineRun` and `TaskRun` reconcilers. Therefore, we must have the same deterministically-generated resolution request name in both places, using the predictable eventual `TaskRun` name and namespace. We also want to make sure that the created `ResolutionRequest` has the appropriate owner reference, hence still passing a `kmeta.OwnerRefable` to `NewResolver` as well as the name and namespace. This is still in alpha. Signed-off-by: Andrew Bayer <[email protected]>
Changes
Prior to this commit the API fields for remote resolution were just
stubs with no functionality.
This commit adds initial functionality: support in
pipelineRef
. You can now pull in pipelines directly from a git repo. This feature is in alpha. To actually see anything happening a dev also needs to deploytektoncd/resolution
and thegitresolver
./kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes