-
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
Move remote resolution out of alpha #5515
Conversation
/wip |
The following is the coverage report on the affected files.
|
03fa4ec
to
6b88794
Compare
The following is the coverage report on the affected files.
|
/test check-pr-has-kind-label |
@abayer: The specified target(s) for
The following commands are available to trigger optional jobs:
Use 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. |
6b88794
to
5df2e62
Compare
The following is the coverage report on the affected files.
|
5df2e62
to
de4b925
Compare
The following is the coverage report on the affected files.
|
/assign @jerop @lbernick @vdemeester @pritidesai |
/retest |
de4b925
to
b0f4d2d
Compare
/hold After discussion with @vdemeester about whether we should stop having the separate
|
The following is the coverage report on the affected files.
|
Notes about things we should implement for remote resolution (not in this PR):
➜ k get resolutionrequests
NAME SUCCEEDED REASON
git-40e5840171b418bcbd0bfa73defec338 True
git-6ecf81c8e0b418bcbd0c05c1bc3cd0c5 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.
I'm going through the review - so far so good, and sorry about the late review 😓
I'm slightly concerned about moving to beta a feature that we have not tried in dogfooding.
The standard resolution mechanism is still there, so this is probably ok.
Before we use this to fully replace existing features like ClusterTasks
we'll need to get a bit more experience with the feature though.
Also I think we need slightly better YAML test coverage.
We have no single yaml test in CI which with a PipelineTask
that uses remote resolution.
We do have tests of pipelines that use remote resolution but they are excluded form CI. At least for the git resolver it should be easy to host a test pipeline in the pipeline repo?
koparse \ | ||
--path $OUTPUT_RELEASE_DIR/release.yaml \ | ||
--path $OUTPUT_RELEASE_DIR/minimal-release.yaml \ |
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.
Why do we need two parameters $IMAGES
and $RESOLVER_IMAGES
and calling koparse twice?
Couldn't this be condensed into one now that the default release file includes all images?
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.
@vdemeester is the one to ask. =)
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.
So, today, we are shipping release.yaml
and resolvers.yaml
. This would make it so that release.yaml
has the resolvers by default, but I would like to keep a release.yaml that doesn't have those as well (and thus also keep resolvers.yaml).
Maybe instead of using ko resolve
multiple time, we could use yq
to generate new files with the thing we want to filter out. (And this would also be true for the -t
as we could remove the tag part from it using yq
).
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.
My question was not about koparse
, not ko resolve
actually.
The ko resolve
calls should be fine, since the built images will be in the cache so it won't actually build the same image more than once.
The koparse
is not a big deal, but I would prefer a simpler script / logic where possible.
The split was done because of v0.40, now we could revert that and go back to one koparse
invocation and fewer params in the pipeline/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.
oh boy, yq
? I have no idea what to do there. =) If we can't do it via multiple koparse
etc calls, I'd really prefer we just have release.yaml
with everything in it.
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, for now, I'd say let's keep minimal-release.yaml
etc, and not let that question block this PR, but make a final decision before v0.41 releases and if we decide to just have release.yaml
, I'll do a quick followup PR to remove minimal-release.yaml
and resolvers.yaml
. @afrittoli @vdemeester does that sound good?
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 :)
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 opened #5607 for that discussion.
Whoops! I meant to add a test using And done - #5604 |
07039d6
to
707edb7
Compare
The following is the coverage report on the affected files.
|
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.
Still going through the PR, still looking good, I left some comments.
I'm a bit confused about the alpha/beta flags in the reconciler and reconciler testing.
Also I would like to see in the PR/commit message/release notes all relevant changes introduced by the PR please 🙏
@@ -34,7 +36,7 @@ type Resolver struct { | |||
requester remoteresource.Requester | |||
owner kmeta.OwnerRefable | |||
resolverName string | |||
params map[string]string |
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.
Could you add context in the commit/PR message about this change?
It doesn't seem to be strictly required for the v1beta1
version of remote resolution.
It would have been nice and easier to review to have that as a separate change before the v1beta1
🙏
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.
Will do!
Closes tektoncd#4710 There are two major aspects to this change: * Creating a `v1beta1` for `ResolutionRequest`, changing from `parameters` as a `map[string]string` to `params` (field name rename for `openapi-gen` API rule validation reasons) as a `[]pipelinev1beta1.Param`. This is being done to match `ResolverRef.Params`, which is a `[]pipelinev1beta1.Param`. We originally left `ResolutionRequest.Parameters` as `map[string]string` since it already was that in `v1alpha1` and changing it would require `ResolutionRequest` `v1beta1`, hence doing this now. Changing to `[]pipelinev1beta1.Param` is needed to support array and object params for resolvers, and we're going with a slice rather than a map because that's how you're supposed to do this in Kubernetes. =) * Promoting the remote resolution functionality from `alpha` to `beta`, meaning on by default for `v1beta1` `Pipeline`s etc, and requiring `enable-api-fields: beta` for `v1` `Pipeline`s etc. Additionally, we're undoing the questionable decision to split the resolvers out into `resolvers.yaml`, separate from `release.yaml`, and enabling the built-in resolvers. Deprecation of the legacy `taskRef.bundle` and `pipelineRef.bundle` syntax will be handled in a separate PR (tektoncd#5514). Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
707edb7
to
2bfe381
Compare
There are a few examples tests that use a git clone copied directly from the catalog, e.g. https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/pipelineruns/pipelinerun-with-final-tasks.yaml. (It has the comment "This can be deleted after we add support to refer to the remote Task in a registry (Issue #1839) or add support for referencing task in git directly (issue #2298)". Maybe those can be replaced with git resolution? |
@afrittoli Ok, so we do test a remote-resolved |
The following is the coverage report on the affected files.
|
/retest |
@afrittoli Nah, pretty sure that's just due to GitHub webhooks having problems. /retest |
Rather, GH webhook issues are why the retest isn't firing - the unit test failure is just one of the family of event-related unit test flakes. |
/lgtm |
Changes
Closes #4710
There are two major aspects to this change:
v1beta1
forResolutionRequest
, changing fromparameters
as amap[string]string
toparams
(field name rename foropenapi-gen
API rule validation reasons) as a[]pipelinev1beta1.Param
. This is being done to matchResolverRef.Params
, which is a[]pipelinev1beta1.Param
. We originally leftResolutionRequest.Parameters
asmap[string]string
since it already was that inv1alpha1
and changing it would requireResolutionRequest
v1beta1
, hence doing this now. Changing to[]pipelinev1beta1.Param
is needed to support array and object params for resolvers, and we're going with a slice rather than a map because that's how you're supposed to do this in Kubernetes. =)alpha
tobeta
, meaning on by default forv1beta1
Pipeline
s etc, and requiringenable-api-fields: beta
forv1
Pipeline
s etc. Additionally, we're undoing the questionable decision to split the resolvers out intoresolvers.yaml
, separate fromrelease.yaml
, and enabling the built-in resolvers.Deprecation of the legacy
taskRef.bundle
andpipelineRef.bundle
syntax will be handled in a separate PR (#5514)./kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes