-
-
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-70729] Rework clouds management into multiple pages #7658
Conversation
* Separate entry under Manage Jenkins * One configuration page per cloud * One index page per cloud
Looks really nice, the only cloud I could get to actually work currently is one from mock-slave. (pushed one quick fix for layout) |
Adding Can't save Azure or EC2. Both fail with:
|
Should work now. EC2 has an odd behaviour because the persisted name differs from the name displayed in the UI. |
It looks good to me. I think only thing left is to look at the empty state when there's no clouds. I'm not 100% sold on the table, there's not much being displayed there but I don't think we have anything better. Anyway it's a lot better than before. ATH being checked here: jenkinsci/acceptance-test-harness#1047 |
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.
Why does this not adapt /configureClouds/
, instead creating a separate page? If that's deliberate, why does that page remain, essentially duplicating the UI, and why does it remain linked from the empty All view shown after installation, as well as the admin monitor recommending setup of an agent or cloud?
Was a UI similar to plugin manager's "Available" and "Uploads" being different sections of the same top-level page considered, with "Manage Clouds" one page and "Manage Nodes" the other? If yes, what are the drawbacks compared to completely separate top-level items? Given that clouds create a subset of agents, completely separating them again this way (not even having direct navigation between them) seems very awkward.
The "New Cloud" UI is very awkward when there are no clouds installed, very much unlike /configureClouds/
(which replaces the regular UI with a helpful message). This should be reviewed.
Downstream PRs to cloud implementations like Kubernetes should be filed as needed, if they adapted their UI to show only few fields by default, to limit initial complexity in the potentially giant list (screenshot in PR description).
Permissions checks seem way off, need lots more validation to ensure this works as intended.
core/src/main/resources/jenkins/agents/CloudSet/sidepanel.jelly
Outdated
Show resolved
Hide resolved
There are remaining plugins that do not support custom names (listed above). For these plugins, the user experience is the following:
With that, I think we don't need to keep a fallback UI even for plugins that may not have been updated to support user provided names. |
/label ready-for-merge This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
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.
Not attempting to review this in its entirety, just a buglet I noticed. Fine to restore ready-for-merge
so far as I am concerned.
/label ready-for-merge This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
Follows up jenkinsci#7658 For consistency with 45e656c
Causes JENKINS-71371. |
Causes JENKINS-71825. |
jenkinsci/jenkins#7658 reworks cloud management to use multiple pages instead of a single large page. That rework also requires that a cloud may not be named with an empty string. The docker plugin specifically tested that a cloud was allowed to have an empty string as its name, but performed no other operations with a cloud that is named with an empty string. Cloud named with an empty string may have worked prior to Jenkins 2.403, but they would have been complicated to manage, especially in a controller with multiple clouds defined. A cloud named with an empty string is much more difficult to manage. It is better to mention in the changelog that clouds are no longer allowed to have an empty name rather than wrestling with all the ways that an empty name will break cloud administration. https://issues.jenkins.io/browse/JENKINS-70729 is the enhancement request that implements the change. https://issues.jenkins.io/browse/JENKINS-71825 is the bug report for the automated test failure that started this investigation.
jenkinsci/jenkins#7658 reworks cloud management to use multiple pages instead of a single large page. That rework also requires that a cloud may not be named with an empty string. The docker plugin specifically tested that a cloud was allowed to have an empty string as its name, but performed no other operations with a cloud that is named with an empty string. Cloud named with an empty string may have worked prior to Jenkins 2.403, but they would have been complicated to manage, especially in a controller with multiple clouds defined. A cloud named with an empty string is much more difficult to manage. It is better to mention in the changelog that clouds are no longer allowed to have an empty name rather than wrestling with all the ways that an empty name will break cloud administration. https://issues.jenkins.io/browse/JENKINS-70729 is the enhancement request that implements the change. https://issues.jenkins.io/browse/JENKINS-71825 is the bug report for the automated test failure that started this investigation.
amends jenkinsci#173 due to jenkinsci/jenkins#7658 bumps the baseline to avoid the redirect or adding a TODO
cf. the idea I described in https://groups.google.com/g/jenkinsci-dev/c/71eTUHSFE9I/m/J4Jzx6kwAgAJ
Here are a few screenshots
Details
See JENKINS-70729.
Testing done
Created clouds of type:
name
) is mandatory.name
attribute in UI. BrokengetUrl()
Updated clouds
Deleted clouds
Installed downstream PR for Azure which demonstrates overriding the icon: jenkinsci/azure-vm-agents-plugin#383
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
@Restricted
or have@since TODO
Javadocs, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
, if applicable.eval
to ease future introduction of Content Security Policy (CSP) directives (see documentation).Desired reviewers
@mention
Maintainer checklist
Before the changes are marked as
ready-for-merge
:upgrade-guide-needed
label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).lts-candidate
to be considered (see query).