Hi Luca, I think you are referring to random failures of maven downloads?
We used a couple of countermeasures in the past, all of them proved problematic. We persisted the maven cache so the next by bind mounting a local directory onto the maven cache .m2 . We had nice permission issues and didn‘t triggered when a maven repository went out of business: Our build suceeded but everyone else wasn‘t able to build any more. Since everything now converges to maven central this might not be that big issue any more. A different approach was to use a proxy maven repo, i remember we had issues because it somehow didn‘t work, and we have the hurdle of yet another tool to master. Both of these worked as a workaround, somehow to cut releases. On my daytime job the devs configured their job to prepopulate the maven cache , but I am not a fan of this approach. My next proposal would be to use docker volumes (not bind mounts) for that, so we wont have any permission problems any more and we are left with the server issues going out if business, eventually. To mitigate that it would be easy to simply recreate docker volumes rather to go to all filesystems as root removing directories we needed for the bind mount workaround. We could eventually pair to try to implement that, if you are not too familiar with it. https://docs.docker.com/storage/volumes/ Best Olaf > Am 29.01.2022 um 08:31 schrieb Luca Toscano <[email protected]>: > > Hi everybody, > > I have been seeing build failures for trunk packages due to maven > network failures (mostly connection timeouts). Is there a workaround > for this? For example retrying x times etc.. I am asking mostly > because of ignorance, I am wondering what we do when cutting a release > for example (to avoid re-running the main package build job due to > some package build failures). > > Thanks! > > Luca
