Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: metadata-plugin
-
Similar Issues:
Description
I am unable to completely delete a job. Something is happening where after a delete of the job, the job will get recreated. I believe it has to do with the SaveableOperation class as the run method is being invoked. I inserted some debugging code in this class and noticed that this class is invoked after the delete has been performed.
Steps to reproduce:
Create a new Job
Delete Job
Restart Jenkins
Job exists still but is disabled.
I have attached a junit test for verifying this as being an issue. If you look at the test unit it will perform the delete and grabs the timestamp of the file being created before and after. It will also do an assert if the directory still exists after the reload.
Attachments
Activity
See pull request https://github.com/jenkinsci/metadata-plugin/pull/1 for fix.
Steven Christou
added a comment - See pull request https://github.com/jenkinsci/metadata-plugin/pull/1 for fix. Code changed in jenkins
User: christ66
Path:
src/main/java/com/sonyericsson/hudson/plugins/metadata/contributors/JobContributorsController.java
src/test/java/com/sonyericsson/hudson/plugins/metadata/DeleteTest.java
http://jenkins-ci.org/commit/metadata-plugin/5311c94061a02964f3eb7baea814300e1fc289ad
Log:
[FIXED JENKINS-20113] - Unable to delete metadata job.
Code changed in jenkins
User: Robert Sandell
Path:
src/main/java/com/sonyericsson/hudson/plugins/metadata/contributors/JobContributorsController.java
src/test/java/com/sonyericsson/hudson/plugins/metadata/DeleteTest.java
http://jenkins-ci.org/commit/metadata-plugin/2842fd93fd1f028a93c1583c18f78516fb4ccec2
Log:
Merge pull request #1 from christ66/master
[FIXED JENKINS-20113] - Unable to delete metadata job.
Compare: https://github.com/jenkinsci/metadata-plugin/compare/856b69bc393d...2842fd93fd1f
We're seeing the same behavior using Jenkins 1.550 (latest as of today). Is there any way to find WHAT is calling SaveableListener?
Jonathan Brecher
added a comment - We're seeing the same behavior using Jenkins 1.550 (latest as of today). Is there any way to find WHAT is calling SaveableListener? You need to upgrade the metadata-plugin as the code changes to resolve this issue are for the metadata-plugin and not core Jenkins.
Steven Christou
added a comment - You need to upgrade the metadata-plugin as the code changes to resolve this issue are for the metadata-plugin and not core Jenkins. We don't have the metadata-plugin installed at all.
I guess that means I need to open a new issue. I'll go do that...
Jonathan Brecher
added a comment - We don't have the metadata-plugin installed at all.
I guess that means I need to open a new issue. I'll go do that... SORRY!! It seems that my attachments destined for JENKINS-26957 were attached here by mistake. Could somebody delete please! Thanks
Ioannis Moutsatsos
added a comment - - edited SORRY!! It seems that my attachments destined for JENKINS-26957 were attached here by mistake. Could somebody delete please! Thanks 
Looks like a race condition. Something (TBD) is calling SaveableListener as or right before the job is being deleted. A SaveableOperation task is scheduled, waits a second (thus ensuring that the job has been deleted before it proceeds!), then calls save() on the job and so recreates the config.xml that had just been removed. At least this is what I think is happening. So the fix would be to either make the save operation synchronous (if the unspecified deadlock issues are no longer a consideration); or to explicitly check for the job having been deleted by the time it runs.