Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39559

Job Config History Plugin saving config for a node other than the one being edited

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor

      Saving configuration changes on some agents* results in config-history being updated for a different node. IE making changes to labels for Agent A, press save, the config-history is updated for Agent B, with the current configuration from Agent B. The history.xml file shows that I was the user making the change to Agent B. If I make another change to Slave A and save, Agent C config-history is updated with current configuration from Agent C.

      To be clear:

      1. Current agent config.xml files are not altered in any unintended way, only the config-history files
      2. When saving the agent configuration, the agent configuration that is actually saved is incrementing alphabetically.
      3. The above problem is happening on every save of the agents configuration. definite and repeatable

      Further:
      The above problem seems to be causing an undesired effect in leaving the agent in a disconnected state. However, this is not repeatable.
      The workaround is to re-save the configuration. Which then resumes connectivity between agent and master.

      * some in this case is 6 windows slaves (out of 246 mixed linux and windows slaves currently connected to master), the 6 agents aren't named sequentially and weren't connected to master at the same time

          [JENKINS-39559] Job Config History Plugin saving config for a node other than the one being edited

          James Nord added a comment - - edited

          this has also shown to lead to deadlocks as serialising the xml for a node may take out some locks - so when serialising other nodes where the locks are not held you can get out of order locking and then deadlocks.

          James Nord added a comment - - edited this has also shown to lead to deadlocks as serialising the xml for a node may take out some locks - so when serialising other nodes where the locks are not held you can get out of order locking and then deadlocks.

          brian hewson added a comment -

          Is there more information I can provide to help with this issue?

          brian hewson added a comment - Is there more information I can provide to help with this issue?

          Robin Schulz added a comment -

          The problem here is that ComputerListener's methods don't provide information on which node's config has changed. So every node's config is persisted. Having activated the option to not save duplicates, this should still only save the config of the node for which you changed something unless you haven't altered other config.xmls manually or in another way that has not triggered the Saveable listener.

          Robin Schulz added a comment - The problem here is that ComputerListener 's methods don't provide information on which node's config has changed. So every node's config is persisted. Having activated the option to not save duplicates, this should still only save the config of the node for which you changed something unless you haven't altered other config.xmls manually or in another way that has not triggered the Saveable listener.

            stefanbrausch Stefan Brausch
            brian_hewson brian hewson
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: