<p>I'm running gitlab (hosted) and use the docker runner with build image <code>maven3.5.4-jdk10</code> for CI. I'm trying to move this setup to a working Kubernetes cluster on Azure using the gitlab-provided helm charts plus Minio for caching. Everything is working fine, runner is registered, pods are deployed, build starts, </p>

<pre><code>$ mvn --settings .m2/settings.xml --batch-mode --errors --show-version -X -T 1C dependency:tree
</code></pre>

<p>goes download artifacts. Now every single time after x amount of files downloaded the build stops, runner zips the cache and is finished as "successful". Even with Maven debug enabled there is not a single message indicating any problem.</p>

<p>Repeating above process a number of times, due to caching, more and more files get downloaded until finally, the build is able to reach the compile phase. The same problem is seen when changing the build image to maven 3.3.9, and the same problem after rebuilding the cluster.</p>

<p>Is there any known reason why <code>mvn dependency:tree</code> should stop in the middle of what it's doing without any indication?</p>

andig
<p>Not really, from the Kubernetes side. </p>

<p>However, running in Kubernetes is different than say running on your laptop, since you are sharing the server resources with other pods and workloads. It's hard to tell unless you share what's running on your cluster, but it could be you just don't have any resources in your cluster and as the size of your cache increases then maven requires more CPU, memory, etc.</p>

<p>You could try configuring <a href="https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/" rel="nofollow noreferrer">Resource and Limits</a> for your pods so that you have guarantees in terms of when you run maven in the cluster. You could also try clearing the cache before any new job/build starts.</p>
