Local settings.xml not picked up by Jenkins agent about docker-maven HOT 6 CLOSED

The issue is related to the -u uid:gid that jenkins uses to run the container. As you may know the image you are running only has the user root created, so when jenkins pass its own uid and gid , there is no entry for the user and consequentially no $HOME declared for it.

If you only want to run the build independently of the user, you can use the follow as agent:

agent {
        docker {
            image 'maven:3-alpine'
            args '-v $HOME/.m2:/root/.m2:z -u root'
            reuseNode true
        }
}

A few notes:

1. if you notice the volume I am using with the flag z, as I am going to build with root, I need to tell docker that this volume will be shared among another containers, and then preventing access denied from my jenkins container (running with the user jenkins not root)
2. I tell jenkins to reuseNode, so any other stage using the same image, will be executing on the same container (it is just to speed up the provisioning time)

from docker-maven.

@gonzalesraul That works! Thank you for the help.

from docker-maven.

Is there any other workaround for it? Of course I want a new clean Maven container for each job run. And there must be a way to inject a custom settings.xml if container is not run as root.

In Jenkins, if the container is forced to run as root via

--user root:root

subsequent runs will fail as Jenkins is unable to delete generated directories.

Seems to be a long-time issue with this image, see: #14, #16, #18,

from docker-maven.

@steinsag yes, there is a few but I would suggest these below:

1. Instead of use declarative docker agent to run on jenkins you could use docker cli (using sh commands), and then you pass the parameters on your own. As I stated earlier, the issue is that docker agent always will bind jenkins uid:gid, consequentially there is no user on the target container. If took control of that part, you could run as root, mount the workspace or whatever (use :z option on docker to share info amongst different contexts) and then get the result after all.

2. The other option involves extending the maven image by adding jenkins user and jenkins agent, and then use that extended image as docker agent on your pipeline. That way you would be fine once the user will exists and jenkins has the agent to run as usual.

from docker-maven.

I think this is an issue with jenkins, and somewhat fixed based on #16 (comment)

jenkinsci/docker-workflow-plugin#63 should have solved this without an image change.

from docker-maven.

@carlossg the issue resides on Jenkins for sure.

I think the root cause to getting these behaviors, resides on uid:gid binding on Jenkins to the container startup.

Your mention to jenkinsci/docker-workflow-plugin#63 only resolves the entrypoint option for scripted pipeline.

It still might not be on the maven container scope, but still a valid issue when used with docker-workflow-plugin

from docker-maven.