-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Jenkins 1.518
I have seen matrix sub-jobs abort before even starting a build on a slave machine. On investigating further I see that for some reason the sub-job config.xml files contain the tags:
<disabled>true</disabled>
even though the matrix job is enabled and indeed the top level config.xml contains:
<disabled>false</disabled>
This seems to happen to jobs that have been copied from other matrix jobs where the axis configurations have changed a few times.
Since the user has no control over this tag it must be redundant. I think that the code should force the disabled tag to be false for all child jobs.
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-19179] Matrix sub-jobs get disabled
Artur Szostak
created issue -
Artur Szostak
added a comment - I remember trying that very trick a few times, but with limited success. However, I did find a workaround that has worked every time so far. One needs to go to the Jenkins script console and run the following script:
def jenkins = hudson.model.Hudson.instance;
def job = jenkins.getItem("job-name");
for (cfg in job.getItems()) {
cfg.disabled = false;
println(cfg.disabled);
}
Note: the job-name above should be replaced with the appropriate matrix job name that is causing the problem.
This script effectively runs through the sub-jobs of the matrix job and forces them to enabled.
Artur Szostak
added a comment - I remember trying that very trick a few times, but with limited success. However, I did find a workaround that has worked every time so far. One needs to go to the Jenkins script console and run the following script:
def jenkins = hudson.model.Hudson.instance;
def job = jenkins.getItem("job-name");
for (cfg in job.getItems()) {
cfg.disabled = false;
println(cfg.disabled);
}
Note: the job-name above should be replaced with the appropriate matrix job name that is causing the problem.
This script effectively runs through the sub-jobs of the matrix job and forces them to enabled. | Component/s | New: matrix-project [ 18765 ] | |
| Component/s | Original: matrix [ 15501 ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Assignee | New: Oleg Nenashev [ oleg_nenashev ] |
| Link |
New:
This issue is related to |
I propose to explicitly prohibit the disabling of Matrix configurations.
It would just workaround issues like JENKINS-18164.
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/matrix/MatrixConfiguration.java
src/main/resources/hudson/matrix/Messages.properties
http://jenkins-ci.org/commit/matrix-project-plugin/fe786b4b47e8137f538e451a3ed888ace5e85780
Log:
[FIXED JENKINS-19179] - Prevent the disabling of Matrix Configurations
This change blocks calls, which try to disable matrix configurations.
MatrixConfiguration::isDisabled() always returns the parent's value.
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
As noted in this Q&A the workaround is to browse to configure on the matrix configuration and uncheck Disabled.
Clearly one bug is that a matrix configuration got disabled somehow, i.e. the MatrixConfiguration.disabled field was set. How?
The next bug is that configure (and configSubmit) are even available on matrix configurations (albeit without a sidebar link), when there does not seem to be any intent for these config.xml files to be individually configurable. (The configure page shows all sorts of options, such as SCMs, which are definitely not supposed to be allowed on configurations.) These URLs should presumably be blocked. The config.xml URL is also available; in GET mode this might be OK, but a POST to it is probably also bad.
Then there is the problem that despite the fact that MatrixConfiguration.supportsMakeDisabled is false, so no UI button appears to explicitly enable or disable the project, isDisabled is not overridden to unconditionally return true.