On Tue, 23 Sep 2025 at 7:05 PM, David Alayachew wrote:

Hello Jenkins Team,

I have a GitHub repo with a Maven project with over 50 sub-modules, all in 
the same repo. All of those sub-modules are under a single aggregate pom 
file.

I created a single Maven job pointed to the aggregate pom, and on the first 
run, all sub-modules were discovered as expected.
 

Now, I want these jobs to build in parallel. So, I checked the checkbox 
that says "Build modules in parallel".

But when I looked at the nodes used, all of the builds occurred on a single 
node, even though there are many other nodes available. And to be clear, it 
was using all executors of that node, but still limiting itself to a single 
node.

So, that meant that, even though the queue had 40+ jobs queued up, once all 
the executors on that single node were occupied, it didn't matter if any of 
the other nodes were free, no work would be picked up by them.

On a second attempt, a different node was used, but the same behaviour -- 
all sub-modules only executed on this second node.

Is this behaviour overridable? 


No, that is not overridable as far as I know.
 

Or am I potentially doing things wrong? Again, I am only using the Jenkins 
Maven Job, not a Jenkinsfile or anything like that.


I think it is a mistake to use the Maven job type in Jenkins.  Use a 
Pipeline.  It gives you more precise control and allows you to choose 
techniques that better suit your specific needs.

Refer to the "Risks" section 
<https://plugins.jenkins.io/maven-plugin/#plugin-content-risks> of the 
Maven job type documentation for a detailed description why you should use 
a Pipeline job instead of the Maven job type.
 

And as a workaround, I could just make a new Maven Job for each Maven 
sub-module. Doing it this way, now I do actually run on many free nodes.

But that has the downside of increasing the maintenance burden immensely. 
Remember, I have over 50 sub-modules. If I need to add new functionality, 
that's 50 Jenkins jobs that I need to update. Not ideal at all.

 
Yes, if you need fine-grained control of job parallelism and then you'll 
need to manage that fine-grained control.

Mark Waite 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/jenkinsci-users/b59c26a3-c445-4759-8016-4515c13b3803n%40googlegroups.com.

Reply via email to