Code changed in jenkins
User: Oleg Nenashev
Path:
core/src/main/java/hudson/model/AbstractProject.java
http://jenkins-ci.org/commit/jenkins/1b0d8fb63aa98a666f656a60c4c6802c6d023dba
Log:
[FIXED JENKINS-24340] - Do not disable jobs if supportsMakeDisabled() returns false

This changes prevents the improper usage of method without the preliminary supportsMakeDisabled() check.
As an example, Subversion plugin behaves in such way (JENKINS-24341)

Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
(cherry picked from commit a78f1d3246cfdbee96820d5629dbb8676a3ca19a)

Integrated in jenkins_main_trunk #4292
[FIXED JENKINS-24340] - Do not disable jobs if supportsMakeDisabled() returns false (Revision 1b0d8fb63aa98a666f656a60c4c6802c6d023dba)

Result = UNSTABLE
ogondza : 1b0d8fb63aa98a666f656a60c4c6802c6d023dba
Files :

• core/src/main/java/hudson/model/AbstractProject.java

I believe this change caused a small issue in the Ivy Plugin and likely in the Maven Plugin as well.

Both of those plugins, when configured to build modules as separate jobs, disable their child projects if they no longer exist in the source on a new build. In both cases, the child projects IvyModule and MavenModule are not user-disableable, but the code does still need to be able to disable them programatically.

On Jenkins versions with this change, removing a module from source control, or renaming a module, will leave 'ghost' module projects around that Jenkins still tries to build, but which are not listed as modules in the parent project anymore.

tbingaman Yes, seems it's another issue related to the conflict of internal APIs and UIs. On the other hand, there was an issue in Subvrsion plugin before the fix.

My proposal would be to update Ivy and Maven plugins, because the fix appears in multiple LTS lines. `disabled` and `isDisabled()` are accessible to child classes, so it should be possible. Have you created JIRA issues for this plugins? If no, I'll do it.

Yep, sounds good. No tickets logged yet, if you could create them that'd be awesome.

I ended up fixing our fork of the Ivy Plugin just by overriding makeDisabled in IvyModule using the method from before this change. Can confirm that that has restored the previous behaviour for us. c3c8ce3