-
-
Notifications
You must be signed in to change notification settings - Fork 8.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
[JENKINS-71737] Fix redirect when submitting cloud changes #8310
Conversation
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.
(amending #7658)
Can you file a Jira ticker and mark as an LTS candidate? |
Can this not be tested with e.g. |
Converting to draft as there is more work to be done here. |
c1d02fe
to
a0a3e9c
Compare
On the long run, having consistency is better than having a local optimum. This is probably an opportunity to generalize the current "rename" concept that currently only applies to |
Not great UX, they could have already done a bunch of changes, if apply isn't possible it shouldn't be there, i.e. imo better to be consistent and use a different page. |
This reverts commit 108bc22.
I have been able to manually confirm the changes are working for |
After confirming the downstream plugin behaviors with the incremental, I believe this PR is ready for review again. |
now that jenkinsci/azure-vm-agents-plugin#462 and jenkinsci/ec2-plugin#892 have been merged, I updated all the incrementals of the downstream plugins and confirmed cloud creation, renaming, updating, and deletion are working as expected. |
* @since TODO | ||
*/ | ||
@Restricted(ProtectedExternally.class) | ||
public interface Renamable { |
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.
Having a hard time understanding the relationship between this interface and Node
/Slave
. Should they implement this interface or not? If so, why don't they? If not, why does renaming work without issue there?
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 idea was to make them implement this interface as well: #8310 (comment)
I had originally tried to do it the same way as Computer, but it always failed testing it in other plugins such as ec2
and azure-vm-agents
.
Looking back now, I realize the problem was always the cloudName
vs name
issue that was finally identified and corrected. I have just pushed up a second, simpler, version of a fix for this bug. See #8505
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.
@timja reminded me that one of the big issues was that apply does not work correctly when changing names and other config parts: #8505 (review)
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.
To fully answer the original comment, I guess it is more a matter of being consistent across our UIs? Changing the name of a Node
isn't an issue because there is no Apply
button. Should we implement this interface in Node
, the apply button could be added back in.
Given how this PR affected a bunch of downstream PRs, it's probably best to implement this interface one component at a time.
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.
On the flip side, why not remove the Apply button from Cloud
to make it consistent with Node
? That's inconsistent with AbstractItem
, but so is the status quo where Node
is inconsistent with AbstractItem
. And at least it fixes the bug.
A request to defer implementing this interface in Node
is effectively a request to introduce debt. I would not automatically reject such a request, but I think it needs to be justified, and merely mentioning "how this PR affected a bunch of downstream PRs" does not seem like a valid justification to me. And I think the intention behind the request is to implement in stages (which is fine, if the rest of the stages are actually finished in a timely fashion, something which almost never happens in my experience whenever someone makes such a request), but an unintentional consequence is that the design of the interface might turn out worse.
When defining a new interface, it is important to consume it in at least three places before shipping it to ensure the design is correct. If you implement it only once, it probably won't support a second implementation. If you implement it only twice, it will probably support a third implementation with difficulty. If you implement it three or more times, the interface will probably work fine. Will Tracz calls this "The Rule of Threes" (Confessions of a Used Program Salesman, Addison-Wesley, 1995).
So my perspective is that the third implementation should be in scope for this PR not only in order to make the implementation complete but also to validate the design of the interface.
|
||
@Override | ||
public boolean isNameEditable() { | ||
return 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 must be missing something, because I can't see how renaming is exposed in the GUI for, say, the Docker plugin. I have a Docker cloud created against a core before this PR and the current release of Docker plugin, and I have another Docker cloud created against a core after this PR and jenkinsci/docker-plugin#1016. I can visit confirm-rename
manually and rename the cloud there, but I can't get the link to show up anywhere in the GUI for either of my two clouds. Please forgive me if I am doing something wrong on my side.
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 rename page gets exposed via TransientActionFactoryImpl
, which is hidden in RenameAction
. I had to get pointed in the right direction as well when I was first looking into this.
I was able to create an old docker cloud and then when I changed to jenkinsci/docker-plugin#1016, was able to see the old docker cloud name and then rename it though. But to be fair, I didn't really have any parameters filled in my cloud.
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 still couldn't find where RenameAction
is visible in the UI on Cloud
with these changes even after looking on several pages. I must be missing something.
if (validationError.kind != FormValidation.Kind.OK) { | ||
throw new Failure(validationError.getMessage()); | ||
} | ||
this.name = newName; |
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.
Shouldn't we be doing something to persist this change to disk, the same way it would be persisted immediately if we changed it via the configure page?
formData.put("name", name); | ||
Cloud result = cloud.reconfigure(req, formData); | ||
if (!(result.name).equals(this.name)) { | ||
// Do not rename the cloud in the config page. Use doConfirmRename() |
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.
Who is the intended audience for this imperative statement? If this is temporary logic to support some sort of migration period, then a warning should be logged that the cloud is using an unsupported mechanism that will be eventually removed in the future. (And if so, that also raises the question, why support this but not creating a new cloud with a plugin that still uses the configure page during the same migration period?)
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.
Well, originally I had it as a form exception and I just wanted to block old/incorrect implementations in the downstream plugins' config.jelly
. My rationale for a quiet ignore was that there is a large sidebar link that says rename so if hopefully no one would get too frustrated before noticing that. I couldn't find a nice way to pop up a warning message for someone who clicked save. Apply, was possible, but I couldn't figure out when you clicked saved.
Another attempt I tried to disable the save button if the name was changed, but it looked like i couldn't do that with the submit button, and I would have to do something with the regular button. At that point I stopped since I did not think it was worth the risk doing changes I wasn't very sure of doing in the first place.
Now that If the simpler fix is accepted, I guess this PR might be considered a proposed UI enhancement? If there is a consensus to continue it, that is. |
(reviewed the other change it has an issue that I don't think you can solve with it) |
Please take a moment and address the merge conflicts of your pull request. Thanks! |
closing in favor of #8505 |
Discovered in jenkinsci/ec2-plugin#875
Changing the cloud node name returns a
404
. The cloud node name does get changed successfully, it is just the redirect is bad because it is trying to go to the old cloud name.Testing done
Added test changing cloud name. Test fails with the existing implementation and now passes in this PR.
Downstream plugin testing:
mesos-plugin: [JENKINS-71737] make MesosCloud name uneditable mesos-plugin#420 (best effort, not familiar with gradle builds) - Last significant release was 3 years ago, so not sure if this is a priority herePR on hold as the gradle builds in this repo do not support jenkins incrementalsProposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
Desired reviewers
@mention
Before the changes are marked as
ready-for-merge
:Maintainer checklist