While using gradle-jenkins-plugin, I noticed that the deleteJenkinsItem task will throw an error if the job you're trying to delete is being viewed on the Jenkins server by a user. It throws a "500 Internal Error".
Running this same experiment using curl ( send a POST doDelete to the job ) reveals the error message is:
...\builds\1\log: The process cannot access the file because it is being used by another process.
Is there another Jenkins API call that allows one to safely delete a job despite being viewed by another user? This doesn't sound like such a great idea but neither does throwing a generic HTTP 500 error.
At the very least, it would be helpful if the gradle-jenkins-plugin threw a more descriptive error. Documenting the behavior in this ticket will at least warn other users. I'm very new to Jenkins so I don't know if this is just an architectural limitation.
Regardless, your plugin is fantastic. I'm using the cloudbees folder plugin support (serviceOverrides). Works great. Thank you for building it.
While using gradle-jenkins-plugin, I noticed that the deleteJenkinsItem task will throw an error if the job you're trying to delete is being viewed on the Jenkins server by a user. It throws a "500 Internal Error".
Running this same experiment using curl ( send a POST doDelete to the job ) reveals the error message is:
...\builds\1\log: The process cannot access the file because it is being used by another process.
Is there another Jenkins API call that allows one to safely delete a job despite being viewed by another user? This doesn't sound like such a great idea but neither does throwing a generic HTTP 500 error.
At the very least, it would be helpful if the gradle-jenkins-plugin threw a more descriptive error. Documenting the behavior in this ticket will at least warn other users. I'm very new to Jenkins so I don't know if this is just an architectural limitation.
Regardless, your plugin is fantastic. I'm using the cloudbees folder plugin support (serviceOverrides). Works great. Thank you for building it.
best regards,
Mark