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

Post build action deploy to maven repository does not honor the "private maven repository" setting

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None

      When using the post-build action to deploy to the maven repository it looks for artifacts in ~/.m2/repository - and not the private maven repository for the job.

          [JENKINS-8711] Post build action deploy to maven repository does not honor the "private maven repository" setting

          pgweiss added a comment -

          OK, I've opened JENKINS-8939 and assigned it to you. I'd still like to know the particulars of the case that this bug was meant to solve.

          pgweiss added a comment - OK, I've opened JENKINS-8939 and assigned it to you. I'd still like to know the particulars of the case that this bug was meant to solve.

          Olivier Lamy added a comment -

          so the patch has been reworked to prevent JENKINS-8939.
          war for test uploaded here : http://people.apache.org/~olamy/jenkins/

          Olivier Lamy added a comment - so the patch has been reworked to prevent JENKINS-8939 . war for test uploaded here : http://people.apache.org/~olamy/jenkins/

          I've used the patch as well as the latest release of Jenkins.

          The post build action says that it's using the correct maven settings.xml but does not honor the <localRepository> that's set.

          The Maven RedeployPublished use remote maven settings from : /privdir/djbs002/.m2/settings.xml

          Caused by: org.apache.maven.wagon.TransferFailedException: Specified destination directory cannot be created: ~/.m2/repository/XXX

          Shaun Thompson added a comment - I've used the patch as well as the latest release of Jenkins. The post build action says that it's using the correct maven settings.xml but does not honor the <localRepository> that's set. The Maven RedeployPublished use remote maven settings from : /privdir/djbs002/.m2/settings.xml Caused by: org.apache.maven.wagon.TransferFailedException: Specified destination directory cannot be created: ~/.m2/repository/XXX

          Same here in the logs I have : "Maven RedeployPublished use remote maven settings from : /home/kgr_mvn/.m2/settings.xml"
          This is correct however: localRepository value is ignore.

          Configuring the job to use a per job repository does not work either (<localRepository class="hudson.maven.local_repo.PerJobLocalRepositoryLocator"/>).

          The publication fails because it tries to use the default path ($HOME/.m2/repository) ...

          Philippe Jandot added a comment - Same here in the logs I have : "Maven RedeployPublished use remote maven settings from : /home/kgr_mvn/.m2/settings.xml" This is correct however: localRepository value is ignore. Configuring the job to use a per job repository does not work either (<localRepository class="hudson.maven.local_repo.PerJobLocalRepositoryLocator"/>). The publication fails because it tries to use the default path ($HOME/.m2/repository) ...

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          src/main/java/hudson/maven/RedeployPublisher.java
          http://jenkins-ci.org/commit/maven-plugin/ee09340fdc372b6ed7b4ebfddb73960d5af115f3
          Log:
          JENKINS-8711 Post build action deploy to maven repository can fail using "private maven repository" option

          Originally-Committed-As: 7dc2652349b2e94de23d024cf1ad69309f3c92e0

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: src/main/java/hudson/maven/RedeployPublisher.java http://jenkins-ci.org/commit/maven-plugin/ee09340fdc372b6ed7b4ebfddb73960d5af115f3 Log: JENKINS-8711 Post build action deploy to maven repository can fail using "private maven repository" option Originally-Committed-As: 7dc2652349b2e94de23d024cf1ad69309f3c92e0

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          src/main/java/hudson/maven/MavenModuleSetBuild.java
          src/main/java/hudson/maven/RedeployPublisher.java
          http://jenkins-ci.org/commit/maven-plugin/1e34e36ba2b1c8a44a0d67ad74df407e7ba6368a
          Log:
          [FIXED JENKINS-8939] Fix for JENKINS-8711 breaks deployments with credentials
          take care about using settings from the remote node

          Originally-Committed-As: 1458f93a3c809bf8b5a4f2b1ed3de3769bffc715

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: src/main/java/hudson/maven/MavenModuleSetBuild.java src/main/java/hudson/maven/RedeployPublisher.java http://jenkins-ci.org/commit/maven-plugin/1e34e36ba2b1c8a44a0d67ad74df407e7ba6368a Log: [FIXED JENKINS-8939] Fix for JENKINS-8711 breaks deployments with credentials take care about using settings from the remote node Originally-Committed-As: 1458f93a3c809bf8b5a4f2b1ed3de3769bffc715

          I just had an issue that let me discover this one which is for now considered as a normal behavior (https://github.com/jenkinsci/maven-plugin/blob/master/src/main/java/hudson/maven/RedeployPublisher.java#L203)
          Not totally wrong as I wrote a part of this code and that's right that the upload is done from master (that's why it requires to archive artifacts to move back artifacts from the agent to master) and thus on master the workspace can be missing thus using always the shared $HOME/.m2/repository is a solution.
          The problem is that it may create conflict between jobs trying to upload at the same time (that's why the ability to use a repository local to each workspace was added).
          I don't have a real solution.
          Enforcing to create a local workspace on master for the job could be a solution with less conflicts but it may always happen (if another build is starting on master for the same job).
          Using a temp directory will enforce maven to download the earth each time ....
          Perhaps the best solution nowadays could be to use the deployAtEnd option of the recent version of the maven-deploy-plugin : https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd

          Arnaud Héritier added a comment - I just had an issue that let me discover this one which is for now considered as a normal behavior ( https://github.com/jenkinsci/maven-plugin/blob/master/src/main/java/hudson/maven/RedeployPublisher.java#L203 ) Not totally wrong as I wrote a part of this code and that's right that the upload is done from master (that's why it requires to archive artifacts to move back artifacts from the agent to master) and thus on master the workspace can be missing thus using always the shared $HOME/.m2/repository is a solution. The problem is that it may create conflict between jobs trying to upload at the same time (that's why the ability to use a repository local to each workspace was added). I don't have a real solution. Enforcing to create a local workspace on master for the job could be a solution with less conflicts but it may always happen (if another build is starting on master for the same job). Using a temp directory will enforce maven to download the earth each time .... Perhaps the best solution nowadays could be to use the deployAtEnd option of the recent version of the maven-deploy-plugin : https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd

          I'll wait for a 2.9 release before using AtTheEnd option because for now it is doing it silently due to a bug. It was fixed in incoming 2.9 : http://svn.apache.org/viewvc/maven/plugins/trunk/maven-deploy-plugin/src/main/java/org/apache/maven/plugin/deploy/DeployMojo.java?r1=1531347&r2=1540334&pathrev=1540334&diff_format=h

          Arnaud Héritier added a comment - I'll wait for a 2.9 release before using AtTheEnd option because for now it is doing it silently due to a bug. It was fixed in incoming 2.9 : http://svn.apache.org/viewvc/maven/plugins/trunk/maven-deploy-plugin/src/main/java/org/apache/maven/plugin/deploy/DeployMojo.java?r1=1531347&r2=1540334&pathrev=1540334&diff_format=h

          Why is the deploy done from the master, shouldn't it be done from the slave where the job was built?

          Daniel Serodio added a comment - Why is the deploy done from the master, shouldn't it be done from the slave where the job was built?

          No possible, the workspace may not be available when using a ReDeploy

          Arnaud Héritier added a comment - No possible, the workspace may not be available when using a ReDeploy

            Unassigned Unassigned
            davidkarlsen2 David Karlsen
            Votes:
            2 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: