-
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
Revert removal of embedded TaskRun status in API. #6206
Conversation
@wlynch: GitHub didn't allow me to request PR reviews from the following users: JeromeJu. Note that only tektoncd members and repo collaborators can review this PR, and authors cannot review their own PRs. 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. |
/kind bug |
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.
a few q's:
- I'm assuming we'll backport to v0.45?
- How long do you think we need to keep this in place for?
- This seems like it would apply to removal of any fields (and we are about to remove PipelineResources); can we create general guidance for how to remove fields? (not a blocker for this PR)
Yes please, though this only requires a client library release (e.g. you can just cut a tag). This has no impact on the server images.
Depends. At minimum I'd keep this in place until the current LTS releases that default to full statuses cycle out (which I think is only v0.41.0). If you want to be extra conservative this should stay in place until v0.44.0 cycles out (since users could still opt back into full statuses). Since this is only preserving an API field, my hope is the maintenance burden for this is very low.
I can kick this off in another PR! |
That makes sense; I think v0.44 would make sense since we'd want to support until it's not possible to opt into full statuses. Can you add a comment to the code about when this can be removed?
Yeah that would be my expectation as well
thank you! |
Thanks @wlynch , I would assume we might also need to mention this in the |
This is an interesting question 🤔 My initial thought is that this is no longer a server feature, so we don't necessarily need to include it here anymore - it just needs to be documented in the client. I don't have strong feelings about this though - @tektoncd/core-maintainers thoughts? |
// clientsetscheme "k8s.io/client-go/kubernetes/scheme" | ||
// aggregatorclientsetscheme "k8s.io/kube-aggregator/pkg/client/clientset_generated/clientset/scheme" | ||
// ) | ||
// import ( |
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 might need to be restored
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 was all from ./hack/update-codegen.sh 🤷
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 might want to have something similar for "go types".. but then, if the deprecated function already have the correct "annotation" it should shows in godoc, ide(s), … |
I would have never deleted this entry in the
The reasons being: The pipelines project is constantly moving but the users are not constantly adopting those changes. It is not possible in practice to adopt them on a regular basis. It always helps to track how we landed to a certain decision. Keeping the history falls in the bucket of anything we can do to help the operators/consumers/users to design their workflows, pipelines, and API. |
That makes sense for helping users to keep in track. In that case, shall we have a separate table representing the 'removed' or 'already deprecated' APIs in |
53bc736
to
4124ed6
Compare
Deprecation documentation is covered by #6209 - any other blockers for this PR? |
@wlynch I don't think so. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
/lgtm |
/hold @wlynch could you please squash the commits? |
@wlynch seems like you also need to rebase you PR 🤔 |
This is a partial revert to undo the removal of the type from the API. Because minimal statuses were only being populated by default in v0.44.0, the removal of this field in v0.45.0 makes it difficult for clients >= v0.45 to safely communicate with older server versions (in particular LTS releases). Only the API type is needed - newer server versions do not need to populate or support it.
4124ed6
to
8a21576
Compare
Done. /remove-hold |
/assign @vdemeester |
/milestone Pipelines v0.46 I'd like to track this as part of the v0.46 milestone so another release doesn't ship without this. |
@JeromeJu Looks like Lee's out - can I get an LGTM? 🙏 |
/lgtm |
Changes
This is a partial revert to undo the removal of the type from the API. Because minimal statuses were only being populated by default in v0.44.0, the removal of this field in v0.45.0 makes it difficult for clients >= v0.45 to safely communicate with older server versions (in particular LTS releases).
Only the API type is needed - newer server versions do not need to populate or support it.
Fixes tektoncd/chains#715
/kind bug
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