-
Notifications
You must be signed in to change notification settings - Fork 268
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
[WIP] Add new cancel states for "graceful" cancel #2378
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @williamlfish. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
@AlanGreene The pr we discussed a while back. Sorry it took me a bit to get to it 😅 but hopefully we can start from here? At the end of the day, just wanted to have it on your radar. thanks! |
Thanks for the PR @williamlfish. I've just taken a very quick look and it seems like a solid start. It'll likely be a few days before I can do a proper review but I'll try to give some early feedback soon. /ok-to-test |
@williamlfish: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
1 similar comment
@williamlfish: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
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 seeing some odd behaviour where the state sent in the API call doesn't always match the selected option in the UI. Possibly in part related to mismatch between the value in the local component state and the value in localStorage, commented below with a suggestion to address that. There may be some other issues causing the mismatch too.
That said the overall structure looks good. Just some styling / content issues to take care of as previously discussed but we're good to proceed with the approach 👍
Thanks for tackling this @williamlfish and apologies for the delay getting around to reviewing 😸
@@ -0,0 +1,65 @@ | |||
/* |
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 not sure we need this new component since it's only used in one place and just wraps existing components with no additional logic.
return API.cancelPipelineRun({ | ||
name, | ||
namespace, | ||
cancelState: payload[0].value |
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.
Let's extract this to a variable, const cancelState = 'PipelineRunCancelled';
and use it in both places. It makes it easier to read without having to backtrack to parse the payload
object.
defaultMessage: 'Cancel' | ||
}); | ||
|
||
const canceledWithFinally = intl.formatMessage({ |
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.
cancelledWithFinally
- double 'l' for consistency with the state value. Same in a few other places too
secondaryButtonText: intl.formatMessage({ | ||
id: 'dashboard.modal.cancelButton', | ||
defaultMessage: '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.
no need for this, it's the default text on the secondary button already
setCancelState(state); | ||
setDefaultCancelState(state); |
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.
ideally we would only be setting this in one place and reading from that single place consistently.
We could use a similar pattern to the one in ListPageLayout for the pagination settings. Set the value in component state, useEffect
to listen for changes and write to localStorage
. This way they should always be in sync and there's one trigger for the update.
We would read from localStorage
on mount and use it to populate the initial value in useState
. From that point on the component state is our source of truth, until the page is reloaded.
@@ -214,3 +214,31 @@ export function setTheme(selectedTheme = getTheme()) { | |||
); | |||
localStorage.setItem('tkn-theme', theme); | |||
} | |||
|
|||
function sanatizeCancelState(state) { |
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.
typo: sanitize
if (valid) { | ||
return state; | ||
} | ||
return 'PipelineRunCancelled'; |
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 have a different default here vs. the end of getDefaultCancelState
below which calls this function. Should they be consistent / combined?
@AlanGreene thanks for the review, and no worries about the delay, we are all busy 😅! Speaking of busy, I should have time to get to these changes before next week. thanks again! |
@AlanGreene sorry for not having this out! My household got a case of the vid, so the rest of us have been hunkering down and testing everyday. All that said, I don't have childcare at the moment and free time is out the window. I'll get to it as soon as i can, but I don't want to be a blocker either so if you or anyone else is interested, please feel free to add to this. Thanks! |
No worries at all, look after yourself and your family. |
const versionCheck = parseInt(pipelinesVersion.split('.')[1], 10); | ||
const allowCancelOptions = !Number.isNaN(versionCheck) && versionCheck > 34; |
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.
note to self: another option would be to use something like semver
to perform the comparison, especially if we're going to end up with similar checks for other features. This could help with compatibility checks especially as Tekton Pipelines starts removing some of the v1alpha1 APIs (e.g. Conditions)
e.g.
const minVersion = '>=0.35.0';
const allowCancelOptions = semver.satisfies(pipelinesVersion, minVersion);
Depending on the size the package contributes to the build output we may want to import only the specific function used, there are some docs included for how to achieve that.
@williamlfish: PR needs rebase. 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. |
Changes
Updates to use the new cancel statuses, with backwards compatibility for pipeline controllers that have not updated to consume them. There are still some changes needed for the wording around the new statuses from a ux perspective. A lot has been discussed in the issue here.
One of the ideas was to add an info icon with a tool tip for and explanation, and from what I can tell the carbon radio buttons break when trying to add the icons ( I don't do a lot of front end, so could be a me problem 😅 ). So there is still the need to explain them, and a way to present. So I admit, this pr may not be ready, but perhaps a conversation starter?
Juggling the version, and the status passed in is a little cumbersome and hopefully something that can be removed relatively soon.
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)