[JIRA] [maven] (JENKINS-22104) Deploy to maven Repository does not update Snapshot maven-metadata.xml
Steve Eckerlein updated JENKINS-22104 Deploy to maven Repository does not update Snapshot maven-metadata.xml Change By: Steve Eckerlein (11/Mar/14 9:56 AM) Description: we migrate from Artifactory a week ago, and we were using Artifactory Deploy Plugin to post build deploy our artifact.As we went to Nexus, we now use the Post build deploy feature of embedded Maven Project plugin.Everything seems to works, but the maven-metadata.xml are not updated when artifacts are uploaded. - I run many tests, and mining into logs (as we got a Apache Front of our Nexus), and i saw that the plugin download (twice) the maven-metadata from Nexus, and upload one just after (that the normal behaviour - except the twice thing). - After re-reading the apache logs, the metadata is simply not deployed. The log show the metadata of the artifact version, not the mave-metadata.xml with all version. We have tested without nexus, by deploying in a file system. The behaviour is the same, and the issue is still here. So Nexus is not involved. But when i look into the file (maven-metadata.xml) the new snapshot version is not present. As our integration process rely on this metadata, we are some kind of blocked (the workaround is to schedule a task in Nexus to rebuild metadata, but this is not "live")Am I missing something ?Here is the apache log :XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 200 341XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 200 40XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom HTTP/1.1" 201 -XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom.md5 HTTP/1.1" 201 -XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom.sha1 HTTP/1.1" 201 -XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 200 341XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 200 40XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 201 -XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.md5 HTTP/1.1" 201 -XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 201 -here is the Jenkins logs :Mar 10, 2014 11:22:51 AM org.apache.maven.cli.logging.Slf4jLogger infoINFO: Uploading repository metadata for: 'snapshot com.socgen.fwk.socle:socle-architecture-transverse:2.13.0-SNAPSHOT'Some attachment: - a screen of a section of my repo, and at the same the corresponding maven-metadata.xml- the configuration of my post deploy task (not unique version - even if instable) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscr
[JIRA] [maven] (JENKINS-22104) Deploy to maven Repository does not update Snapshot maven-metadata.xml
Steve Eckerlein commented on JENKINS-22104 Deploy to maven Repository does not update Snapshot maven-metadata.xml After further investigation, the problem occur only if "unique version" if disabled in the job configuration. The maven-metadata.xml is correctly generated if the checkbox is checked. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-22104) Deploy to maven Repository does not update Snapshot maven-metadata.xml
Steve Eckerlein created JENKINS-22104 Deploy to maven Repository does not update Snapshot maven-metadata.xml Issue Type: Bug Assignee: Unassigned Attachments: axe_transverse_mainline_int Config [Jenkins] - Google Chrome.jpg, maven-metadata.xml, socle-transverse.jpg Components: maven Created: 10/Mar/14 3:26 PM Description: we migrate from Artifactory a week ago, and we were using Artifactory Deploy Plugin to post build deploy our artifact. As we went to Nexus, we now use the Post build deploy feature of embedded Maven Project plugin. Everything seems to works, but the maven-metadata.xml are not updated when artifacts are uploaded. I run many tests, and mining into logs (as we got a Apache Front of our Nexus), and i saw that the plugin download (twice) the maven-metadata from Nexus, and upload one just after (that the normal behaviour - except the twice thing). But when i look into the file (maven-metadata.xml) the new snapshot version is not present. As our integration process rely on this metadata, we are some kind of blocked (the workaround is to schedule a task in Nexus to rebuild metadata, but this is not "live") Am I missing something ? Here is the apache log : XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 200 341 XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 200 40 XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom HTTP/1.1" 201 - XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:50 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom.md5 HTTP/1.1" 201 - XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/socle-architecture-transverse-2.13.0-SNAPSHOT.pom.sha1 HTTP/1.1" 201 - XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 200 341 XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "GET /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 200 40 XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml HTTP/1.1" 201 - XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.md5 HTTP/1.1" 201 - XXX.XXX.XXX.XXX - - [10/Mar/2014:11:22:51 +0100] "PUT /nexus/content/repositories/snapshots/com/socgen/fwk/socle/socle-architecture-transverse/2.13.0-SNAPSHOT/maven-metadata.xml.sha1 HTTP/1.1" 201 - here is the Jenkins logs : Mar 10, 2014 11:22:51 AM org.apache.maven.cli.logging.Slf4jLogger info INFO: Uploading repository metadata for: 'snapshot com.socgen.fwk.socle:socle-architecture-transverse:2.13.0-SNAPSHOT' Some attachment: a screen of a section of my repo, and at the same the corresponding maven-metadata.xml the configuration of my post deploy task (not unique version - even if instable) Environment: Linux Red Hat - Jenkins 1.537 - Nexus 2.7.1 Project: Jenkins Priority:
[JIRA] (JENKINS-16046) Sonar Plugin uses wrong maven repository
Steve Eckerlein
commented on JENKINS-16046
Sonar Plugin uses wrong maven repository
I faced the same issue, and i bypassed it by adding this parameter to sonar additional settings in global jenkins configuration :
-Dmaven.repo.local=${PWD}/maven-repositories/${EXECUTOR_NUMBER}
With this, the executor repository is used.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14247) Master Executor Needed for SCM polling even with slaves
Steve Eckerlein commented on JENKINS-14247 Master Executor Needed for SCM polling even with slaves If i define a system environment variable PATH with cleartool the problem is resolved. Tested on a test platform. But on my production network, i have no rights. I can't extend PATH and i face this problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14247) Master Executor Needed for SCM polling even with slaves
Steve Eckerlein created JENKINS-14247 Master Executor Needed for SCM polling even with slaves Issue Type: Bug Assignee: Vincent Latombe Components: clearcase Created: 28/Jun/12 2:52 PM Description: At work, in my configuration, the master only do balancing stuff. The master as no executor, but many slaves do the builds. When the plugin do a scm-polling, if no executor was set to the master (0 executor) the plugin does not append path to cleartool command. In my configuration, it fail because cleartool is not in the PATH. (i have not the rights to define env variable in the system) If i set an executor on the master, the path set in the clearcase installation field is taken. (even if the job is forced to run on a slave) Even if i try to manualy set clearcase path on slaves, in clearcase installation field, or in PATH variable, it does not work. Here the trace when an executor is setted : Started on Jun 28, 2012 4:37:12 PM [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool desc -fmt %[found_bls]Xp\n stream:IM_Ass@/vobs/pvob_ati baseline:intg-metier_INITIAL@/vobs/pvob_ati [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool desc -fmt %[component]Xp\n baseline:intg-metier_INITIAL@/vobs/pvob_ati component:intg-metier@/vobs/pvob_ati [jenkins_im_test-ass_dyn] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool pwv -root /view/jenkins_im_test-ass_dyn [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool lsview jenkins_im_test-ass_dyn jenkins_im_test-ass_dyn /Clearcase/views/siciceda/jenkins_im_test-ass_dyn.vws [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool startview jenkins_im_test-ass_dyn [jenkins_im_test-ass_dyn] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool lshistory -all -since 28-jun-12.14:12:10utc+ -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \"%[activity]Xp\" \n%c\n' -branch brtype:IM_Ass -nco vobs/vob_ati/intg-metier [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool desc -fmt %[found_bls]Xp\n stream:IM_Ass@/vobs/pvob_ati baseline:intg-metier_INITIAL@/vobs/pvob_ati [im_test_ass_build] $ /produits/clearcase/opt_ibm/RationalSDLC/clearcase/bin/cleartool desc -fmt %[component]Xp\n baseline:intg-metier_INITIAL@/vobs/pvob_ati component:intg-metier@/vobs/pvob_ati Done. Took 2.2 sec No changes Here a trace when no master executor is set : Started on Jun 28, 2012 4:39:12 PM [im_test_ass_build] $ cleartool desc -fmt %[found_bls]Xp\n stream:IM_Ass@/vobs/pvob_ati FATAL: Cannot run program "cleartool" (in directory "/applis/iced/jenkins/shared/slave0001/workspace/im_test_ass_build"): java.io.IOException: error=2, No such file or directory java.io.IOException: Cannot run program "cleartool" (in directory "/applis/iced/jenkins/shared/slave0001/workspace/im_test_ass_build"): java.io.IOException: error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at hudson.Proc$LocalProc.(Proc.java:244) at hudson.Proc$LocalProc.(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:709) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:934) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:901) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
[JIRA] (JENKINS-11024) Some commands don't work when using _jenkins-cli.jar with -i switch, get-job and update-job for sure, not certain about others
[ https://issues.jenkins-ci.org/browse/JENKINS-11024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160881#comment-160881 ] Steve Eckerlein commented on JENKINS-11024: --- The build command work, but you have to give anonymous read access to your Project1. Then CLI command will see it. Must be a visibility issue... > Some commands don't work when using _jenkins-cli.jar with -i switch, get-job > and update-job for sure, not certain about others > -- > > Key: JENKINS-11024 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11024 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: CLI >Reporter: Timothy Meazell > > Add keys for authenticated login. Works fine with who-am-i, enable-job, > disable-job, delete-job, create-job, but get-job and update-job fail claiming > there is no job by that name. The very same command line with enable-job (as > well as the others) works fine. > Workaround is to see if enable-job fails (which it will if there is no job by > that name, which was the point of using get-job), then delete-job and > create-job instead of update-job if the job already exists. Note that this > workaround causes the loss of job history upon deletion. > Diagnostics: > % java -jar jenkins/_jenkins-cli.jar -s http://localhost:9090/ -i > jenkins/id_rsa get-job trunk-pacman.integration.vdev-regression > No such job 'trunk-pacman.integration.vdev-regression' > java -jar jenkins-cli.jar get-job args... > Dumps the job definition XML to stdout > JOB : Name of the job > --username VAL : User name to authenticate yourself to Jenkins > --password VAL : Password for authentication. Note that passing a >password in arguments is insecure. > --password-file VAL : File that contains the password > % java -jar jenkins/_jenkins-cli.jar -s http://localhost:9090/ -i > jenkins/id_rsa enable-job trunk-pacman.integration.vdev-regression > % echo $? > 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
