|
||||||||
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better.
To fix the problem the code has to be fixed in the following way.
In PrioritySorterQueue.java the method getPriority has to be changed
from:
[..]
AbstractProject<?, ?> project = (AbstractProject<?, ?>) buildable.task;
priority = project.getProperty(PrioritySorterJobProperty.class);
[..]
to:
[..]
AbstractProject<?, ?> project = (AbstractProject<?, ?>) buildable.task;
PrioritySorterJobProperty priority = null;
if (project instanceof MatrixConfiguration) {
ItemGroup<?> parent = project.getParent();
if (parent instanceof AbstractProject<?, ?>){ priority = ((AbstractProject<?, ?>)(parent)).getProperty(PrioritySorterJobProperty.class); }
} else { priority = project.getProperty(PrioritySorterJobProperty.class); }
[..]
Then the priority from the axises are resolved from the parent matrix because the axis itself does not have the property attached.
According to the higher number -> job starts first - problem the comparitor (same java-file) has to be changed
to:
[..]
public int compare(BuildableItem arg0, BuildableItem arg1) { // Note that we sort these backwards because we want to return // higher-numbered items first. Integer priority1 = getPriority(arg0); return priority1.compareTo(getPriority(arg1)); }
[..]
then the comment is correct - jobs with higher numbers are started first...
And also the adjusting-method has to be changed to adjustedPriority -= ... but this i've never tested