-
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 resolution types to the API #4502
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/kind feature |
The following is the coverage report on the affected files.
|
@@ -261,6 +261,63 @@ func TestTaskRunSpec_Invalidate(t *testing.T) { | |||
}, | |||
wantErr: apis.ErrInvalidValue("breakito is not a valid breakpoint. Available valid breakpoints include [onFailure]", "debug.breakpoint"), | |||
wc: enableAlphaAPIFields, | |||
}, { |
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 some test cases with valid taskrefs for the new syntax?
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, updated with tests of valid resolution syntax when alpha gate is enabled.
@@ -1471,6 +1471,24 @@ | |||
} | |||
} | |||
}, | |||
"v1beta1.ResolverRef": { |
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.
Just for my own understanding what is this file for? Are the changes generated or manual?
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's generated by, I think, ./hack/openapigen.sh
I believe swagger.json
can be used to generate API clients for other programming languages. I don't know of any examples of folks using it, though.
@@ -370,9 +370,10 @@ func TestPipelineRun_Validate(t *testing.T) { | |||
|
|||
func TestPipelineRunSpec_Invalidate(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.
similar comment as for TaskRef, could you add a test case where the ref is valid?
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 test for taskref with resolver field + alpha gate and a test for taskref with resolver field + resource fields + alpha gate.
Love the incremental PR approach @sbwsg 💃 🎉 !! |
The following is the coverage report on the affected files.
|
/lgtm |
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 @sbwsg for the iterative approach in implementing Remote Resolution 😀
Left some comments about the types ResolverRef
:
Resolver
- considering using string alias instead of string (K8s convention)Resource
- considering usingParameters
instead of map (K8s convention)
What do you think about adding the relevant documentation for the API change and validation so that we can review it alongside the change? (we can add a bolded disclaimer that the functionality doesn't work yet, even though users can pass in the fields)
// Resource contains the parameters used to identify the | ||
// referenced Tekton resource. Example entries might include | ||
// "repo" or "path" but the set of params ultimately depends on | ||
// the chosen resolver. | ||
// +optional | ||
Resource map[string]string `json:"resource,omitempty"` |
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 wondering about usingmap[string]string
for Resource
- could we use Parameters
instead?
Especially considering that the proposal suggests using object Parameters
in this field when it's available - maybe using a list of string Parameters
here would help in the transition later?
Note that the fields under
resource:
are validated by a resolver, not by Tekton Pipelines. TEP-0075 (Dictionary
Params) describes adding support for JSON object schema to Params. It would make sense to bring in the same schema support for theresource:
field as well and eventually resolvers might be able to publish the schema they accept so that Pipelines can enforce it during validation of aTaskRun
orPipelineRun
.
~ TEP-0060
K8s API convention encouraging use of sub-objects instead of maps: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-of-named-subobjects-preferred-over-maps
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 for the feedback. I've changed this to use the following syntax:
taskRef:
remote: git
resource:
- name: repo
value: https://github.com/tektoncd/catalog.git
- name: path
value: /task/golang-build/0.3/golang-build.yaml
// Resolver is the name of the resolver that should perform | ||
// resolution of the referenced Tekton resource, such as "git". | ||
// +optional | ||
Resolver string `json:"resolver,omitempty"` |
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.
The TEP proposes a specific set of resolvers: git
, bundle
and in-cluster
What do you think about using aliases for the strings, instead of strings directly, and adding validation for resolvers themselves?
K8s API convention encouraging use of string aliases when fields will have a list of allowed values (enumerations): https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#constants
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.
This field is intentionally free-form. The resolution feature is intended to allow integration with any resolver an operator wants to install and that could include ones that Tekton hasn't explicitly named in its source code. e.g. "svn", "bzr", "gcs"
So, I guess I don't see this being in the spirit of what the Resolution TEP is aiming to achieve for the Tekton project but I also don't want to introduce freeform data if you feel strongly that you'd prefer to have the options explicitly named. Let me know.
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 for the additional context!
How about we declare the Resolver
type, specify the ones we provide, then integrators can specify their own:
# in tekton pipelines
type Resolver string
const (
git Resolver = "git"
bundle Resolver = "bundle"
cluster Resolver = "cluster"
)
# in an integration
const (
svn tekton.Resolver = "svn"
bzr tekton.Resolver = "bzr"
gcs tekton.Resolver = "gcs"
)
Similarly to how we use selection.Operator from K8s apimachinery in operator field in when
expressions
What do 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.
OK, I've updated the type from string
to v1beta1.ResolverName
.
/assign |
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.
|
I've added initial documentation to |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
TEP-0060 adds remote resource resolution to Tekton Pipelines, allowing PipelineRuns and TaskRuns to reference Pipelines and Tasks in remote places like git repos. This PR adds the initial alpha syntax for the remote resolution feature to the v1beta1.TaskRef and v1beta1.PipelineRef types along with validation for them. Some initial documentation is added describing the syntax for remote tasks and pipelines.
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.
excited to try this out soon, thank you @sbwsg 🎉
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerop 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 |
Reopened the issue tracking the flakey test: TestTaskRunPipelineRunCancel /test pull-tekton-pipeline-alpha-integration-tests |
/lgtm |
Changes
TEP-0060 introduces remote resource resolution to Tekton Pipelines, allowing PipelineRuns and TaskRuns to reference Pipelines and Tasks in remote places like git repos.
This PR adds the fields for the remote resolution feature to the
v1beta1.TaskRef
andv1beta1.PipelineRef
types. Also includes validations and unit test coverage. These fields can only be included when theenable-api-fields
feature-flag is set toalpha
. Even then, utilizing these fields only results in the reconcilers printing errors.Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes