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.