[JENKINS-76317]: Add support to define maintenance windows for Clouds by prathamalwayscomeslast · Pull Request #320 · jenkinsci/agent-maintenance-plugin

prathamalwayscomeslast · 2025-12-20T22:21:56Z

Comprehensive solution for JENKINS-76317 i.e. adding cloud maintenance windows.

fixes #337

Implementation details

Added MaintenanceTarget a general model class that represents a TargetType (AGENT, CLOUD)
TargetType + targetName serialization to identify targets
Making MaintenanceLink and MaintenanceAction more generic to allow extension for Cloud
Support for bulk actions added via MaintenanceLink
Backwards compatiblity is taken care of

Testing done

Manually tested existing agents and clouds to ensure it is backwards compatible
Built successfully with mvn clean install and then ran with mvn hpi:run (skipped tests for now)

Submitter checklist

Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
Ensure that the pull request title represents the desired changelog entry
Please describe what you did
Link to relevant issues in GitHub or Jira
Link to relevant pull requests, esp. upstream and downstream changes
Ensure you have provided tests that demonstrate the feature works or the issue is fixed

…pport clouds. - Added `MaintenanceTarget.TargetType.CLOUD` + `toKey()` serialization. - Made `MaintenanceAction` more generic to support `Cloud` - Extending bulk addition of `MaintenanceWindow`s to `Cloud` - UI coverage: Replicated existing agent specific UI for clouds Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2025-12-20T22:53:53Z

I'm open to any suggestions about change in the approach. Unit tests will be added in a day or two. My first idea was to make AbstractMaintenanceAction and making other classes more generic like that, and then implement Agent and Cloud functionalities in their respective subclasses. But that seemed kinda overengineered idea so I sticked with this simpler solution instead. I can give it a shot if that looks like a better idea though

mawinter69 · 2025-12-21T00:23:20Z

Some considerations:
The MaintenanceWindow class has many properties which are specific to agents. E.g takeOnline, keepUpWhenActive and maxWaitMinutes are not used for the cloud. So showing them in the UI and persisting them doesn't make really sense. Those would only make sense if those settings are applied to running agents that have been provided by the cloud. But I'm not sure if this will be possible at all. Right now there is code the actively avoid that Maintenance Windows can be set on cloud agents.

I would prefer when the cloud maintenance windows on the MaintenanceLink page are in a separate table. Also there is an add button that will add new maintenance windows where you can use label expressions. That will not work for clouds in that way. While clouds can react on labels I think right now a cloud should be taken offline completely.

mawinter69 · 2025-12-21T00:16:37Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceAction/config.jelly

+  <l:layout title="Edit Maintenances" norefresh="true">
+      <j:if test="${it.isAgent()}">
+          <st:include it="${it.getAgentComputer()}" page="sidepanel.jelly"/>
+      </j:if>


clouds also have a sidepanel so that should be included.

Okay I have included sidepanel to cloud too. There is an issue here though. When I go to maitenance window on cloud's side panel, it takes me to cloud/cloud-name/maintenanceWindow and then the sidepanel is broken. Now if I go to configure from sidepanel, it directs me to cloud/cloud-name/maintenanceWindow/configure which is the wrong API. Even the status button is now cloud/cloud-name/maintenanceWindow. This only happens with the cloud's sidepanel, the agent's one is working fine. I'm having a hard time finding where this url discrepancy is coming from

That is a bug in the sidepanel.jelly at https://github.com/jenkinsci/jenkins/blob/474f2aa295b1dcfe7578806bcf9ee0d0c610055b/core/src/main/resources/hudson/slaves/Cloud/sidepanel.jelly#L30 and L31. Here it uses a relative url, while it should use an absolute url. I opened jenkinsci/jenkins#26002 for this
And in the agent sidepanel is also a bug when it comes to deleting the agent. There as well it uses a relative url.

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

- Implemented `CloudMaintenanceQueueBlocker` instead of `ProvisioningListener` as it was found to be less reliable. - Separate sections for cloud and agent maintenance windows in `MaintenanceLink` Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2025-12-24T23:19:35Z

Some considerations: The MaintenanceWindow class has many properties which are specific to agents. E.g takeOnline, keepUpWhenActive and maxWaitMinutes are not used for the cloud. So showing them in the UI and persisting them doesn't make really sense. Those would only make sense if those settings are applied to running agents that have been provided by the cloud. But I'm not sure if this will be possible at all. Right now there is code the actively avoid that Maintenance Windows can be set on cloud agents.

I would prefer when the cloud maintenance windows on the MaintenanceLink page are in a separate table. Also there is an add button that will add new maintenance windows where you can use label expressions. That will not work for clouds in that way. While clouds can react on labels I think right now a cloud should be taken offline completely.

For now, I hide the agent-specific fields for the cloud context. To not persist them, an optimal solution would be to make an abstract base class for MaintenanceWindow but then that would require tons of refactoring everywhere. MaintenanceLink table separation is done.

I also ran into a bunch of problems implementing the ProvisioningListener logic. The code of that does look correct to me, and I tried tweaking it to make it work in anyway, but the builds still ran on the docker cloud even with active maintenance window. So finally, I changed the approach and blocked the queue itself during active maintenance window - CloudMaintenanceQueueBlocker. And it works. Is this an acceptable solution to that? Or should I revert back to ProvisioningListener logic?

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Changes: - Implemented separate form submission paths: JSON for agents, URL params for clouds - Updated doAdd() to handle both agent (JSON) and cloud (URL parameters) submissions - Added cloud maintenance modal with multi select dropdown for cloud selection Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/agent-maintenance.js

mawinter69 · 2025-12-25T22:34:37Z

The queue approach doesn't work well.
When I configure a cloud for a certain label and there is another cloud that also accepts this label or a static agent, then any build is blocked even when the second cloud or the agent would be able to take the job.

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/agent-maintenance.js

+    location.href = 'config';
+  }
+  let table = document.getElementById("maintenance-table");
+  let tbody = table.tBodies[0];


mawinter69 · 2025-12-25T23:16:35Z

With the mock-agent plugin that can also create mock clouds, the approach with the CloudProvisioningListener works fine

prathamalwayscomeslast · 2025-12-26T07:47:13Z

With the mock-agent plugin that can also create mock clouds, the approach with the CloudProvisioningListener works fine

Can you try this:

Make a docker cloud, and add a docker agent template with any label
Create a freestyle job and restrict it to that docker agent label
Create a maintenance window on the docker cloud
Run the freestyle job when maintenance window is active

I have done this and what I see is that the docker cloud still provisions an agent for the freestyle job to run. You can also verify it from the console output. Why does that happen? I have an active maintenance window and CloudProvisioningListener's implementation is supposed to be blocking it

prathamalwayscomeslast · 2025-12-27T05:18:54Z

When I configure a cloud for a certain label and there is another cloud that also accepts this label or a static agent, then any build is blocked even when the second cloud or the agent would be able to take the job.

I was thinking that we should iterate through all the nodes having the label, whichever cloud provisioned node has maintenance window on their respective cloud, it should skip to the next node with that label. But that doesn't seem possible as there's no way to extract getcloudName() or getCloud() from AbstractCloudSlave or AbstractCloudComputer

- Followed the same logic for maintenance windows; splitting into agent and cloud specific jelly files - Reverted back to `CloudMaintenanceProvisioningListener` Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

- Complete refactoring of `MaintenanceActionTest` to include clouds - New: `MaintenanceTargetTest` - Few more improvements in the core Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2026-01-06T15:03:39Z

Hey @mawinter69. The cloud maintenance feature is 95% complete, with most of the unit tests concerning it. The only things left are resolving some tests, doc changes and checkstyle improvements. So with all that aside, is there something I might have missed? Something I should've done differently? I'm open to any suggestions or changing my approach

prathamalwayscomeslast · 2026-01-06T15:22:06Z

Also this issue was great to work on, taught me a lot about Jenkins internals and how the plugins work, as a beginner. This was my second opensource contribution to any project. If there's anywhere you'd want help, some big update like this, I'd love to help!

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

… new documentation for Clouds. Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2026-01-13T12:58:27Z

Heyy there @mawinter69. Almost everything is done now. Unit tests and documentation too. There's some issues in MaintenanceLinkTest in which I would need your help. Aside from that, these changes are ready to be integrated in the plugin I believe. If there's anything else, let me know!

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

mawinter69

I think we that the actions should be separated. There are a lot of if necessary that make the code hard to understand.
e.g. the jelly of MaintenanceLink will then more or less just be adding the stuff for clouds

When a maintenance window for a cloud is over it should automatically be removed like it is done for agents.

The displayname for the MaintenanceLink is still Agent Maintenances. That should include now also clouds. Maybe that can be made dynamic so in case there are no clouds defined it says Agent Maintenances and with clouds it says Agent and Cloud Maintenances

mawinter69 · 2026-01-18T00:31:07Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+
                    <td>
-                      <f:checkbox class="am__checkbox" name="${mid}"/>
+                      <j:if test="${action.isAgent()}">


This distinction is not necessary. The action is guaranteed to be an agent

mawinter69 · 2026-01-18T00:31:40Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                      <j:if test="${action.isAgent()}">
+                        <l:icon src="${action.getAgentComputer().iconClassName}" class="icon-sm am__table-icon"/>
+                      </j:if>
+                      <j:if test="${action.isCloud()}">


remove this if as it is always false

mawinter69 · 2026-01-18T00:31:48Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+
+                    <td>
+                      <nobr>
+                        <j:if test="${action.isAgent()}">


This is always true

mawinter69 · 2026-01-18T00:31:57Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                            ${action.getAgentComputer().displayName}
+                          </a>
+                        </j:if>
+                        <j:if test="${action.isCloud()}">


This is always false

mawinter69 · 2026-01-18T00:33:22Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                    </td>
+                    <td>${m.userid}</td>
+
+                    <j:if test="${action.isAgent()}">


this is always true

mawinter69 · 2026-01-18T01:31:18Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                    <td>${m.reason}</td>
+                    <td>${m.userid}</td>
+
+                    <p:hasAnyPermission it="${app}" permissions="Jenkins.ADMINISTER">


Suggested change

<p:hasAnyPermission it="${app}" permissions="Jenkins.ADMINISTER">

<l:hasPermission it="${app}" permissions="${app.ADMINISTER}">

mawinter69 · 2026-01-18T01:36:30Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                               data-message="${%deleteMaintenanceOf} ${action.target.toKey()}"
+                               data-message-success="${%Maintenance window was successfully deleted}">
+                            <l:icon src="symbol-trash-outline plugin-ionicons-api" class="icon-sm icon-red am__table-icon"
+                                    tooltip="Delete this maintenance window for ${h.escape(action.target.toKey())}"/>


That leads to following tooltip:

That doesn't look good.

Suggested change

tooltip="Delete this maintenance window for ${h.escape(action.target.toKey())}"/>

tooltip="Delete this maintenance window for ${h.escape(c.displayName)}"/>

mawinter69 · 2026-01-18T01:38:01Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                        </td>
+                        <td class="delete">
+                          <div class="am__link-delete"
+                               data-message="${%deleteMaintenanceOf} ${action.target.toKey()}"


Suggested change

data-message="${%deleteMaintenanceOf} ${action.target.toKey()}"

data-message="${%deleteMaintenanceOf} ${c.displayName}"

mawinter69 · 2026-01-18T01:44:31Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+          <button id="add-button-clouds" type="button"
+                  class="jenkins-button jenkins-button--primary">${%Add}</button>
+          <button id="delete-selected-clouds" type="button"
+                  class="jenkins-button je nkins-button--primary ${cloudMwCount==0?'jenkins-hidden':''} delete-selected-button"


typo

Suggested change

class="jenkins-button je nkins-button--primary ${cloudMwCount==0?'jenkins-hidden':''} delete-selected-button"

class="jenkins-button jenkins-button--primary ${cloudMwCount==0?'jenkins-hidden':''} delete-selected-button"

mawinter69 · 2026-01-18T01:46:26Z

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/index.jelly

+                      </td>
+                      <td class="delete">
+                        <div class="am__link-delete"
+                             data-message="${%deleteMaintenanceOf} ${action.target.toKey()}"


The text is wrong, the dialog then contains agent instead of cloud

- Separated agent and cloud actions for `MaintenanceLink` - Removed redundant if statements - Improved docs Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2026-01-24T13:08:28Z

Okay i fixed everything, removed unnecessary if statements, made displayName more dynamic for agents and clouds, maintenance window clean up in clouds just like agents, separated agent and cloud actions.

However, I restored <p:hasAnyPermission it="${c}" permissions="${action.CONFIGURE_AND_DISCONNECT}"> , it did not work. Then I tried <j:if test="${action.hasDeletePermission()}">, the tests still failed for some reason. And they don't seem to work with the previous logic either. I can't navigate to where the problem is... anything to do with BasePermissionCheck?

Also, I added clean up of cloud maintenance windows when they finish. It happens when the cloud is provisioning a node. Does it need to be a periodic check like we do in AgentMaintenanceRetentionStrategy or is the current logic fine?

mawinter69

We have one principal problem. There is no guarantee that the cloud name is unique. While the UI for creating a new cloud initially prevents from creating duplicate clouds, some clouds still overwrite that. e.g. JClouds plugin in the actual config page allows to define a profile and passes this to the super class as the cloud name. In the UI it checks if the name already exists and properly shows a validation error. But you can still save it with this name. In the cloud overview you then see 2 clouds with that name but the second cloud has a different url http://localhost:8080/jenkins/manage/cloud/cloudByIndex/12/. As currently you connect the maintenance windows via the cloud name it would be impossible to determine if a maintenance window is meant for the first or second cloud.
I found following clouds where it is possible to create duplicate names:

And probably more.
Jenkins core solves that by creating a url with an index, but the problem we have here is that we shouldn't rely on the index as it might change between restarts (e.g. some uses config as code and added a new cloud with same name).

I think for clouds we need to persist the action as part of the cloud itself, Cloud is actionable. So in the factory, first check if the cloud already has an action, if not then create it and add it to the cloud via Cloud.addAction. This will persist the action together with the cloud in the config.xml of Jenkins.

I think that requires a separate action for clouds where all the maintenance windows are stored directly in the action. That also means an own MaintenanceWindow implementation I think

mawinter69

I haven't analyzed yet but deleting a maintenance window from the MaintenanceLink page by clicking on the trash can is not working. It shows the wrong text in the dialog and then fails with an exception

2026-01-24 17:19:10.466+0000 [id=171]	WARNING	h.i.i.InstallUncaughtExceptionHandler#handleException: Caught unhandled exception with ID 38a26465-5d98-4b56-8a8c-25b2fc30134d
java.lang.IllegalArgumentException: Invalid maintenance target key: null
	at PluginClassLoader for agent-maintenance//com.sap.prd.jenkins.plugins.agent_maintenance.MaintenanceTarget.fromKey(MaintenanceTarget.java:42)
	at PluginClassLoader for agent-maintenance//com.sap.prd.jenkins.plugins.agent_maintenance.MaintenanceLink.hasPermission(MaintenanceLink.java:291)
	at PluginClassLoader for agent-maintenance//com.sap.prd.jenkins.plugins.agent_maintenance.MaintenanceLink.deleteMaintenance(MaintenanceLink.java:225)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:484)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:497)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:218)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:140)

mawinter69 · 2026-01-24T17:09:46Z

...n/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/cloud-config.jelly

+                <j:if test="${!action.hasCloudDeletePermission()}">
+                  <td/>
+                  <td/>
+                </j:if>>


duplicate >

mawinter69 · 2026-01-24T17:10:40Z

...n/resources/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceLink/agent-config.jelly

+                    </div>
+                  </td>
+                </p:hasAnyPermission>
+              </tr>


missing p:hasNoPermission to insert 2 <td/>

mawinter69 · 2026-01-24T17:11:34Z

src/test/java/com/sap/prd/jenkins/plugins/agent_maintenance/PermissionSetup.java

    Jenkins.MANAGE.setEnabled(true);
    Jenkins.SYSTEM_READ.setEnabled(true);
    Computer.EXTENDED_READ.setEnabled(true);
+    Computer.CONFIGURE.setEnabled(true);


These 2 permissions are enabled by default. No need to set them

mawinter69 · 2026-01-24T17:13:05Z

src/test/java/com/sap/prd/jenkins/plugins/agent_maintenance/PermissionSetup.java

    // System read and computer configure on agent, but not on agentRestricted
    matrixAuth.add(Jenkins.READ, configure);
    matrixAuth.add(Jenkins.SYSTEM_READ, configure);
+    matrixAuth.add(Computer.CONFIGURE, configure);


remove that added line. This is the cause for the test failures. The permissions are added via a node property in BasePermissionChecks just for one agent. But here you grant that globally.

mawinter69 · 2026-01-24T17:13:18Z

src/test/java/com/sap/prd/jenkins/plugins/agent_maintenance/PermissionSetup.java

    // System read and computer configure on agent, but not on agentRestricted
    matrixAuth.add(Jenkins.READ, disconnect);
    matrixAuth.add(Jenkins.SYSTEM_READ, disconnect);
+    matrixAuth.add(Computer.DISCONNECT, disconnect);


remove that added line. This is the cause for the test failures. The permissions are added via a node property in BasePermissionChecks just for one agent. But here you grant that globally.

mawinter69 · 2026-01-24T17:30:38Z

src/main/java/com/sap/prd/jenkins/plugins/agent_maintenance/MaintenanceAction.java

+                        || computer.hasPermission(Computer.EXTENDED_READ))
+                && computer.getNode() != null;
+      }
+      return Jenkins.get().hasPermission(Jenkins.ADMINISTER);


There is the permission Jenkins.SYSTEM_READ This permission is not enabled by default. It allows a read only view to the global configuration. Clouds are visible with this permission so we also need to support that. So in all places replace ADMINISTER with SYSTEM_READ except when it comes to showing delete buttons or in methods that actually delete something. I.e. with SYSTEM_READ I should be able to see cloud maintenance windows but I should not be able to delete or modify them

prathamalwayscomeslast · 2026-01-27T13:57:21Z

I get duplicate cloud name concern. Persisting actions of each cloud sounds okay but how about this - We generate unique id and assign it to each cloud in the config file. Then, that id will be used to deal with maintenance windows. How I'd want these configurations to persist:

Currently we store maintenance windows as clouds/cloud-name/maintenance-windows.xml in our working directory. A better way supporting duplicate names would be clouds/cloud-name/{unique-cloud-id}/maintenance-windows.xml. Say "aws-cloud" currently has three clouds sharing the name, then clouds/aws-cloud directory will have three sub directories representing each cloud sharing the name, named with their corresponding id. And then have their maintenance windows stored under them.

I believe this would be an optimal solution as it would avoid branching from the already working unified architecture that supports agents and clouds both.

prathamalwayscomeslast · 2026-01-30T21:09:06Z

@mawinter69 Is Jenkins.get().save() an expensive call?

- New: `CloudUuidAction` - a minimal action class just for containing the duplicate cloud's UUID. - `CloudUuidStore` - helper for dealing with duplicate clouds. - New `targetKey` format for duplicate clouds - CLOUD:cloud-name:cloud-uuid. While non duplicate clouds' format remains as is. - Saving maintenance-config.xml UUID directory if the cloud is found to have duplicates. - Fixed deletion bugs in `MaintenanceLink`. Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast · 2026-01-31T22:29:08Z

This seemed easier at first but was a pain to work on. At first I thought UUID is a solid enough distinction for same named clouds. So maybe store key value pairs in some .properties file? But that was not enough to know which exact cloud the uuid belongs to, leaving room for ambiguity. So the best stable distinction would be sha-256 hash of the cloud's configuration along with the cloud's name. Nothing can beat this, right? But configurations keep changing all the time, so that means we'd have to keep track of that and keep our hash in sync with the current config. I knew I was over complicating things, turns out the solution was much simpler!

Saving the action with duplicate cloud's UUID under clouds in the global config file. That was it. Some edge cases may not be covered in this change, and the related unit tests with this will be added after some time if that's fine. Permission improvements too (I am thinking of a centralized PermissionHelper class migrating all permission logic there)

prathamalwayscomeslast · 2026-01-31T22:46:47Z

Cloud name duplicacy shouldn't be allowed. Even the documentation in Cloud refers name as a "unique identifier" which isn't true. With that some core API becomes unreliable like Jenkins#getCloud returns only the first cloud matching the name, when there could be multiple. Duplicates may be a rare occurence but edge cases like these may break plugins dealing with clouds. Make it so the duplicate validation cannot be bypassed by any plugin. But the existing duplicate clouds will work as they are, with indexes. You think that's an issue worth raising in the core?

mawinter69 · 2026-02-01T22:01:09Z

I already opened an issue in core that the handling of clouds is broken. There is an open PR jenkinsci/jenkins#26233 that addresses the problem by introducing a UUID for each cloud.
I would propose to wait for that change.

The main problem with the duplicates is that the handling in the UI used an index, but that index is not stable and that leads to weird problems.
The implementation in core was never complete to protect against duplicate names. While when you select a new cloud it prevents from choosing a duplicate name, on the next page clouds could change that name and then it was possible to create duplicates.
But the duplicates names are not a problem for the clouds to do their job.I think now it's too late to fix that in a way that completely avoids duplicate names.

I think my idea earlier to directly save the maintenance windows as part of the action will not work. Looking at the code of the Cloud class it will create a new instance upon saving the configuration and is then not taking over any added actions from the old to the new instance. So the there is no need to call Jenkins.get.save()

- Fixed deletion bugs in `MaintenanceLink`. Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

…f all `MaintenanceTarget`s Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Merging the permission manager changes to the working branch and also reverting the UUID logic.

prathamalwayscomeslast · 2026-02-28T23:34:24Z

Sounds good. Permission checking was a lil haphazard so I added a centralized PermissionManager keeping things cleaner. I'll follow up with some more tests. As for the cloud duplication issue, I reverted it all back until it is fixed in the core. Im also thinking adding a filter maintenance windows option

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

…w: `CloudUuidAction` - a minimal action class just for containing the duplicate cloud's UUID. - `CloudUuidStore` - helper for dealing with duplicate clouds. - New `targetKey` format for duplicate clouds - CLOUD:cloud-name:cloud-uuid. While non duplicate clouds' format remains as is. - Saving maintenance-config.xml UUID directory if the cloud is found to have duplicates. - Fixed deletion bugs in `MaintenanceLink`." This reverts commit 1b8ba9d

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast added 2 commits December 20, 2025 18:59

Changes to keep it backwards compatible

56c87f6

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast requested a review from a team as a code owner December 20, 2025 22:21

mawinter69 mentioned this pull request Dec 20, 2025

JENKINS-76317: Add cloud provisioning listener skeleton #319

Closed

6 tasks

mawinter69 requested changes Dec 21, 2025

View reviewed changes

prathamalwayscomeslast added 2 commits December 25, 2025 11:56

- Fixed UI bugs

e9e1b13

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast commented Dec 25, 2025

View reviewed changes

src/main/resources/com/sap/prd/jenkins/plugins/agent_maintenance/agent-maintenance.js Show resolved Hide resolved

github-advanced-security bot found potential problems Dec 25, 2025

View reviewed changes

prathamalwayscomeslast added 6 commits December 28, 2025 21:16

- RecurringMaintenanceWindows now work for clouds

2dc5106

- Followed the same logic for maintenance windows; splitting into agent and cloud specific jelly files - Reverted back to `CloudMaintenanceProvisioningListener` Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Added some cloud provisioning listener tests

6e78eba

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Handled all possible edge cases for CloudProvisioningListenerTest

5e7eba7

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Added some new tests:

8c46205

- Complete refactoring of `MaintenanceActionTest` to include clouds - New: `MaintenanceTargetTest` - Few more improvements in the core Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Refactored MaintenanceLinkTest for Cloud and fixed some other tests

7ee0628

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Improved some tests

7284c08

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

prathamalwayscomeslast added 2 commits January 11, 2026 00:42

More tests improved.

7b8097f

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Solved most test case issues. Solved all checkstyle violations. Added…

ebe3b0d

… new documentation for Clouds. Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Removed debugging helper statements

83d5b3f

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

mawinter69 requested changes Jan 18, 2026

View reviewed changes

prathamalwayscomeslast added 2 commits January 24, 2026 17:25

- Improved tooltip and badge in MaintenanceLink

9bda3d0

- Separated agent and cloud actions for `MaintenanceLink` - Removed redundant if statements - Improved docs Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Maintenance Window clean up for cloud when a node is being provisioned.

d1f5237

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

mawinter69 requested changes Jan 24, 2026

View reviewed changes

mawinter69 mentioned this pull request Jan 24, 2026

Cloud returns wrong url for itself when more than 1 cloud with same name is configured jenkinsci/jenkins#26174

Open

mawinter69 mentioned this pull request Feb 1, 2026

Use UUID for clouds jenkinsci/jenkins#26233

Open

14 tasks

mawinter69 changed the title ~~[JENKINS-76317]: Extending maintenance support for Clouds~~ [JENKINS-76317]: Add support to define maintenance windows for Clouds Feb 1, 2026

prathamalwayscomeslast added 4 commits February 27, 2026 02:03

- MaintenanceLinkTest issues are resolved, completely.

f666851

- Fixed deletion bugs in `MaintenanceLink`. Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

New helper class: PermissionManager - clean handling of permissions o…

71870b1

…f all `MaintenanceTarget`s Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Integrated the new PermissionManager API to the existing structure

b6e1ace

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Merge branch 'centralized-permissions' into cloud-maintenance

8f40231

Merging the permission manager changes to the working branch and also reverting the UUID logic.

prathamalwayscomeslast added 4 commits March 1, 2026 05:07

Fix compile error

c29ef42

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

Reverting cloud UUIDs

ebba161

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

fix: resolved test failures

568a80c

Signed-off-by: Pratham Vaghela <prathamcomeslast@gmail.com>

	<p:hasAnyPermission it="${app}" permissions="Jenkins.ADMINISTER">
	<l:hasPermission it="${app}" permissions="${app.ADMINISTER}">

	tooltip="Delete this maintenance window for ${h.escape(action.target.toKey())}"/>
	tooltip="Delete this maintenance window for ${h.escape(c.displayName)}"/>

	data-message="${%deleteMaintenanceOf} ${action.target.toKey()}"
	data-message="${%deleteMaintenanceOf} ${c.displayName}"

	class="jenkins-button je nkins-button--primary ${cloudMwCount==0?'jenkins-hidden':''} delete-selected-button"
	class="jenkins-button jenkins-button--primary ${cloudMwCount==0?'jenkins-hidden':''} delete-selected-button"

Uh oh!

Conversation

prathamalwayscomeslast commented Dec 20, 2025 • edited by mawinter69 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implementation details

Testing done

Submitter checklist

Uh oh!

prathamalwayscomeslast commented Dec 20, 2025

Uh oh!

mawinter69 commented Dec 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prathamalwayscomeslast Dec 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prathamalwayscomeslast commented Dec 24, 2025

Uh oh!

Uh oh!

mawinter69 commented Dec 25, 2025

Uh oh!

Check notice

mawinter69 commented Dec 25, 2025

Uh oh!

prathamalwayscomeslast commented Dec 26, 2025

Uh oh!

prathamalwayscomeslast commented Dec 27, 2025

Uh oh!

prathamalwayscomeslast commented Jan 6, 2026

Uh oh!

prathamalwayscomeslast commented Jan 6, 2026

Uh oh!

prathamalwayscomeslast commented Jan 13, 2026

Uh oh!

mawinter69 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prathamalwayscomeslast commented Jan 24, 2026

Uh oh!

mawinter69 left a comment

Choose a reason for hiding this comment

Uh oh!

mawinter69 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prathamalwayscomeslast commented Dec 20, 2025 •

edited by mawinter69

Loading

prathamalwayscomeslast Dec 28, 2025 •

edited

Loading

mawinter69 Jan 24, 2026 •

edited

Loading