-
Bug
-
Resolution: Unresolved
-
Critical
-
None
The flow plugin at startup will delete all old data because it performs a save operation:
"Jenkins initialization thread@2736" daemon prio=5 tid=0x27 nid=NA runnable java.lang.Thread.State: RUNNABLE at hudson.model.listeners.SaveableListener.fireOnChange(SaveableListener.java:81) at hudson.model.AbstractItem.save(AbstractItem.java:521) - locked <0x3690> (a hudson.model.FreeStyleProject) at hudson.model.Job.save(Job.java:180) at hudson.model.AbstractProject.save(AbstractProject.java:306) at hudson.model.Job.addProperty(Job.java:523) at hudson.model.AbstractProject.addProperty(AbstractProject.java:786) at org.jenkinsci.plugins.flow_plugin.FlowProjectListener.addFlowProperty(FlowProjectListener.java:33) at org.jenkinsci.plugins.flow_plugin.FlowProjectListener.onLoaded(FlowProjectListener.java:17) at jenkins.model.Jenkins.<init>(Jenkins.java:857) at hudson.model.Hudson.<init>(Hudson.java:83) at hudson.model.Hudson.<init>(Hudson.java:79) at hudson.WebAppMain$3.run(WebAppMain.java:225)
At startup a flow property is added to each job which triggers a save operation. This happens for any project.
On another note: I am unable to locate the source code for this plugin.
- links to
[JENKINS-42522] FLOW plugin deletes old data on startup
Tony Bridges
added a comment - I hit this issue during an upgrade.
To reproduce :
1. configure the use of a plugin in a job. Call this CanaryPlugin
2. Verify the presence of the CanaryPlugin configuration in XML.
3. Delete the CanaryPlugin that added this data from the file system
4. Upgrade the metadata plugin.
5. Restart.
On startup, the MD plugin upgrade causes the job configuration to be resaved, effectively deleting the configuration for the CanaryPlugin from all jobs.
I ran into this problem when attempting a manual sync of plugins between two systems. The tool used to seed the plugins did not handle internally developed plugins, and the first attempt to restart the system after the upgrade caused the configuration for all internal plugins to be stripped.
The expectation here was that the "missing plugin" error could be addressed post restart by restoring the missing plugins, and restarting again.
Tony Bridges
added a comment - I hit this issue during an upgrade.
To reproduce :
1. configure the use of a plugin in a job. Call this CanaryPlugin
2. Verify the presence of the CanaryPlugin configuration in XML.
3. Delete the CanaryPlugin that added this data from the file system
4. Upgrade the metadata plugin.
5. Restart.
On startup, the MD plugin upgrade causes the job configuration to be resaved, effectively deleting the configuration for the CanaryPlugin from all jobs.
I ran into this problem when attempting a manual sync of plugins between two systems. The tool used to seed the plugins did not handle internally developed plugins, and the first attempt to restart the system after the upgrade caused the configuration for all internal plugins to be stripped.
The expectation here was that the "missing plugin" error could be addressed post restart by restoring the missing plugins, and restarting again. 
Please provide detailed steps to reproduce.