-
Notifications
You must be signed in to change notification settings - Fork 222
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
TEP-0154 Concise Remote Resolver Syntax #1138
TEP-0154 Concise Remote Resolver Syntax #1138
Conversation
/assign @wlynch |
cc @chmouel PTAL (specifically for |
b935354
to
c0f6253
Compare
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
IIUC we loosened the constraints enough that tl;dr this is adding url
to the remote resolver request.
/approve Added a hold in case other reviewers want to take a look before the TEP is merged. Feel free to remove after |
c0f6253
to
9710ad5
Compare
9710ad5
to
7286131
Compare
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.
If we want to be consice, couldn't we use name
for this instead adding url
and duplicating some information (the name) ? I think it would be backward compatible : it's {name}://…
we infer the name and we don't read the rest, it's {name}
only it's the current syntax that applies. In ResolutionRequest
we would pass the url or the parameters and let the resolver handle that (and/or the helper code we provide).
Can we write an example for a custom resolver ? They are part of the resolver "feature set" (to be able to write your own resolver) and thus we should make sure we take them into account in this proposal.
Just the name alone won't help. That's because it then requires that the value starts with the resolver name. And that does not work with something like the http resolver where the scheme could be So in the above case, the name alone does not work. But name with the resolver works because we know where the resolution request is supposed to go:
Can do! |
@chitrangpatel, yeah, as you commented here, we would want "resolver" to be able to say "I handle those sheme", and some sort of priority. Now, even with that, the Some history note (that might not have any "impact"), the current syntax is also there because it was decided to be consistent with the rest of the API (on params). The initial proposal looked like name: …
params:
- foo: bar
- {name}: {value} |
7286131
to
3683ff3
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom, 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 |
/hold cancel |
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
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users. more refactor
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR implements an updated resolver framework with slight updates. This is to avoid backwards incompatibility while implementing [TEP-0154](tektoncd/community#1138). The current framework only works with Params. e.g. The interface has ValidateParams and Resolve which takes in Params. Now that we also need to pass in a `URL`, we need to add new methods and change function signatures which leads to API incompatibility with existing custom resolvers. As a result, when users upgrade to new version of Tekton Pipelines, they will be forced to be compatible with the new format because of the interface changes. This PR tries to make it future proof such that if we add new fields to the ResolutionSpec, it will be handled without the need to break users.
This PR proposes to include a concise remote resolver syntax to reference remote resources.
It addresses the feature request tektoncd/pipeline#7508.
/kind tep