Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-40484

Unable to use withMaven() step inside docker container for old versions of Docker

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I'm not able to use withMaven step inside docker container.

      [Pipeline] withMaven
      $ docker exec ffff env printenv MAVEN_HOME
      $ docker exec ffff env printenv M2_HOME
      $ docker exec ffff env /bin/sh -c "which mvn"
      Using maven exec: /opt/apache-maven-3.3.9/bin/mvn
      Using global settings config with name MavenGlobal
      Replacing all maven server entries not found in credentials list is false
      [Pipeline] {
      [Pipeline] sh
      
      [test-XXX] Running shell script
      nohup: failed to run command `sh': No such file or directory
      
      [Pipeline] }
      [Pipeline] // withMaven

      My Jenkinsfile pipeline:

      node('docker') {
          stage('Checkout') {
              checkout scm
          }
          buildInDocker('linux') {
              stage('Maven') {
                  withMaven(globalMavenSettingsConfig: '11111111-2222-3333-4444-555555555555') {
                          sh 'mvn clean test'
                  }
              }
          }
      }

      It looks like PATH env gets overwritten.

        Attachments

          Issue Links

            Activity

            Hide
            acejam Joshua Noble added a comment - - edited

            I hit this issue again today for the second time. Docker Pipeline 1.14 is unusable and causes `withMaven` to break when used from within a Docker container. Using containers is one of the best features of pipelines, so this is pretty critical functionality IMO.

            Show
            acejam Joshua Noble added a comment - - edited I hit this issue again today for the second time. Docker Pipeline 1.14 is unusable and causes `withMaven` to break when used from within a Docker container. Using containers is one of the best features of pipelines, so this is pretty critical functionality IMO.
            Hide
            acejam Joshua Noble added a comment -

            Any updates on this?

            Show
            acejam Joshua Noble added a comment - Any updates on this?
            Hide
            stodorov Steve Todorov added a comment - - edited

            ++Joshua Noble try reverting to an older version of Docker Pipeline. I have been using the older version since this issue hit me in JENKINS-47805. It seems that you can fix this either by using a mvnw, downgrade to an older version of Docker Pipeline or wait for JENKINS-48050 which looks like it will fix it for good.

            Show
            stodorov Steve Todorov added a comment - - edited ++ Joshua Noble try reverting to an older version of Docker Pipeline. I have been using the older version since this issue hit me in JENKINS-47805 . It seems that you can fix this either by using a mvnw, downgrade to an older version of Docker Pipeline or wait for JENKINS-48050  which looks like it will fix it for good.
            Hide
            acejam Joshua Noble added a comment -

            I spent a good amount of time looking into this and came up with an acceptable workaround that works for my team. We have hundreds of branches across hundreds of repos, so updating all of the Java/Maven related Jenkinsfiles (on every branch) to use $MVN_CMD instead of "mvn" was not going to happen anytime soon. We also had several pending plugin updates, many of which required the latest version of the pipeline-maven plugin. In our case, we have a private internal Docker image that we use for all maven builds. It's forked off the official Docker Hub Maven image and includes a few additional tools and packages that we need.

            What I ended up doing was creating a bash script that simply wraps the "mvn" command and checks for existence of $MVN_CMD. If $MVN_CMD exists, it calls that and passes along the same parameters. If $MVN_CMD doesn't exist, it simply calls the real maven binary located at /usr/bin/mvn. This bash script lives at /usr/local/bin/mvn, which exists in our $PATH before the real maven binary, which is /usr/bin/mvn.

            Simply create a bash script like below, and ensure it has execute permissions: (chmod +x mvn.sh) 

            #!/bin/bash
            
            if [[ -v MVN_CMD ]]; then
              $MVN_CMD "$@"
            else
              /usr/bin/mvn "$@"
            fi
            

            Then inside of your Dockerfile, add the following instruction:

            COPY mvn.sh /usr/local/bin/mvn
            

            This has been tested with the maven:3.5.3-jdk-8 Docker image.

            Show
            acejam Joshua Noble added a comment - I spent a good amount of time looking into this and came up with an acceptable workaround that works for my team. We have hundreds of branches across hundreds of repos, so updating all of the Java/Maven related Jenkinsfiles (on every branch) to use $MVN_CMD instead of "mvn" was not going to happen anytime soon. We also had several pending plugin updates, many of which required the latest version of the pipeline-maven plugin. In our case, we have a private internal Docker image that we use for all maven builds. It's forked off the official Docker Hub Maven image and includes a few additional tools and packages that we need. What I ended up doing was creating a bash script that simply wraps the "mvn" command and checks for existence of $MVN_CMD. If $MVN_CMD exists, it calls that and passes along the same parameters. If $MVN_CMD doesn't exist, it simply calls the real maven binary located at /usr/bin/mvn. This bash script lives at /usr/local/bin/mvn, which exists in our $PATH before the real maven binary, which is /usr/bin/mvn. Simply create a bash script like below, and ensure it has execute permissions: (chmod +x mvn.sh)   #!/bin/bash if [[ -v MVN_CMD ]]; then $MVN_CMD "$@" else /usr/bin/mvn "$@" fi Then inside of your Dockerfile, add the following instruction: COPY mvn.sh /usr/local/bin/mvn This has been tested with the maven:3.5.3-jdk-8 Docker image.
            Hide
            timdowney Tim Downey added a comment -

            Thanks for the writeup Joshua Noble – That's pretty much exactly what Josh Trow and I have done to deal with the problem.

            Show
            timdowney Tim Downey added a comment - Thanks for the writeup Joshua Noble – That's pretty much exactly what Josh Trow and I have done to deal with the problem.

              People

              • Assignee:
                cleclerc Cyrille Le Clerc
                Reporter:
                testuser7 Test User
              • Votes:
                10 Vote for this issue
                Watchers:
                21 Start watching this issue

                Dates

                • Created:
                  Updated: