[JIRA] (JENKINS-13296) Changelists that include excluded files and files outside of the client view will trigger a build.
[ https://issues.jenkins-ci.org/browse/JENKINS-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161027#comment-161027 ] Rob Petti commented on JENKINS-13296: - Yeah, you've definitely found a bug, and a tricky one at that! I'll see if I can figure out how to get it working like it should... > Changelists that include excluded files and files outside of the client view > will trigger a build. > -- > > Key: JENKINS-13296 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13296 > Project: Jenkins > Issue Type: Improvement > Components: perforce >Reporter: Patrick McKeown >Priority: Minor > > If there is already a way to handle this I apologize, looked around but > didn't find anything. > Given a client spec > //depot/test/... //client/test/... > with an exclude list such as > //depot/test/exclude/... > and polling turned on- > if someone submits a changelist with an excluded file and a file outside the > client spec such as > changelist 1234 > //depot/test/exclude/example.txt#1 > //depot/test2/example2.txt#1 > then //depot/test2/example2.txt#1 will trigger the build as it does not match > anything in the exclude list. > I would like a way to consider any files outside of the client spec as > excluded files without actually having to specify them. Thanks! -- 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
[JIRA] (JENKINS-13296) Changelists that include excluded files and files outside of the client view will trigger a build.
[ https://issues.jenkins-ci.org/browse/JENKINS-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti reassigned JENKINS-13296: --- Assignee: Rob Petti > Changelists that include excluded files and files outside of the client view > will trigger a build. > -- > > Key: JENKINS-13296 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13296 > Project: Jenkins > Issue Type: Improvement > Components: perforce >Reporter: Patrick McKeown >Assignee: Rob Petti >Priority: Minor > > If there is already a way to handle this I apologize, looked around but > didn't find anything. > Given a client spec > //depot/test/... //client/test/... > with an exclude list such as > //depot/test/exclude/... > and polling turned on- > if someone submits a changelist with an excluded file and a file outside the > client spec such as > changelist 1234 > //depot/test/exclude/example.txt#1 > //depot/test2/example2.txt#1 > then //depot/test2/example2.txt#1 will trigger the build as it does not match > anything in the exclude list. > I would like a way to consider any files outside of the client spec as > excluded files without actually having to specify them. Thanks! -- 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
[JIRA] (JENKINS-13263) Downstream jobs inherit same changeset
[ https://issues.jenkins-ci.org/browse/JENKINS-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti updated JENKINS-13263: Component/s: display-upstream-changes (was: perforce) > Downstream jobs inherit same changeset > -- > > Key: JENKINS-13263 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13263 > Project: Jenkins > Issue Type: Improvement > Components: display-upstream-changes > Environment: Jenkins ver. 1.456 > Perforce 1.3.11 >Reporter: nicholas blasingame >Assignee: Carl Quinn >Priority: Minor > Labels: perforce, polling, scm > > I have an initial job that syncs to the depot and gets the most up to date > changesets and then triggers the rest of the jobs through a daisy chain. > I know there are features that enable you to pass a changelist via parameters > or counter, but I haven't found any solutions for the jobs posting the same > changeset as the initial job. > It would be nice to have an option that allows downstream jobs to inherit the > same changelog as their parents'. > This is more of a convenience since we can just use deduction to figure out > which tests are using the most recent revisions, but it would be nice to just > be able to see each job tell us what accurate changeset it is using. > Thanks. -- 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
[JIRA] (JENKINS-13263) Downstream jobs inherit same changeset
[ https://issues.jenkins-ci.org/browse/JENKINS-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti resolved JENKINS-13263. - Assignee: Rob Petti (was: Carl Quinn) Resolution: Fixed This information can now be obtained by using the Display Upstream Changes plugin, which will add the list of upstream changes to the build summary. > Downstream jobs inherit same changeset > -- > > Key: JENKINS-13263 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13263 > Project: Jenkins > Issue Type: Improvement > Components: display-upstream-changes > Environment: Jenkins ver. 1.456 > Perforce 1.3.11 >Reporter: nicholas blasingame >Assignee: Rob Petti >Priority: Minor > Labels: perforce, polling, scm > > I have an initial job that syncs to the depot and gets the most up to date > changesets and then triggers the rest of the jobs through a daisy chain. > I know there are features that enable you to pass a changelist via parameters > or counter, but I haven't found any solutions for the jobs posting the same > changeset as the initial job. > It would be nice to have an option that allows downstream jobs to inherit the > same changelog as their parents'. > This is more of a convenience since we can just use deduction to figure out > which tests are using the most recent revisions, but it would be nice to just > be able to see each job tell us what accurate changeset it is using. > Thanks. -- 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
[JIRA] (JENKINS-13297) Make order of main sections the same between 'FreesytleJob' and 'Maven Job'
domi created JENKINS-13297: -- Summary: Make order of main sections the same between 'FreesytleJob' and 'Maven Job' Key: JENKINS-13297 URL: https://issues.jenkins-ci.org/browse/JENKINS-13297 Project: Jenkins Issue Type: Improvement Components: ui-changes Reporter: domi Assignee: domi The order of the main sections of free and maven jobs are like this: free 1. Advanced Project Options 2. Source Code Management 3. Build Triggers 4. Build Environment 5. Build 6. Post-build Actions mvn 1. Advanced Project Options 2. Source Code Management 3. Build Triggers 4a Pre Steps 4b Build 4c Post Steps 5. Build Settings 6. Build Environment 7. Post-build Actions specially the 'Build Environment' seems to be placed at the wrong place for the mvn job - because it is the setup of the job it feels more right to have it at the start of the configuration (like in the free style job). Why there is a 'Build Settings' section in the mvn job but not in the free style job, I don't know... e.g. it contains 'E-mail Notification' which is available in the 'Post-build Actions' of a freestyle job. -- 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
[JIRA] (JENKINS-13297) Make order of main sections the same between 'FreesytleJob' and 'Maven Job'
[ https://issues.jenkins-ci.org/browse/JENKINS-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13297. Resolution: Fixed > Make order of main sections the same between 'FreesytleJob' and 'Maven Job' > --- > > Key: JENKINS-13297 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13297 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: domi >Assignee: domi > > The order of the main sections of free and maven jobs are like this: > free > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4. Build Environment > 5. Build > 6. Post-build Actions > mvn > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4a Pre Steps > 4b Build > 4c Post Steps > 5. Build Settings > 6. Build Environment > 7. Post-build Actions > specially the 'Build Environment' seems to be placed at the wrong place for > the mvn job - because it is the setup of the job it feels more right to have > it at the start of the configuration (like in the free style job). > Why there is a 'Build Settings' section in the mvn job but not in the free > style job, I don't know... e.g. it contains 'E-mail Notification' which is > available in the 'Post-build Actions' of a freestyle job. -- 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
[JIRA] (JENKINS-13297) Make order of main sections the same between 'FreesytleJob' and 'Maven Job'
[ https://issues.jenkins-ci.org/browse/JENKINS-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161029#comment-161029 ] SCM/JIRA link daemon commented on JENKINS-13297: Code changed in jenkins User: imod Path: maven-plugin/src/main/resources/hudson/maven/MavenModuleSet/configure-entries.jelly http://jenkins-ci.org/commit/jenkins/98e75df11d2c574faca67e696ed75c477cb278ad Log: [FIXED JENKINS-13297] Make order of main sections the same between 'FreesytleJob' and 'Maven Job' > Make order of main sections the same between 'FreesytleJob' and 'Maven Job' > --- > > Key: JENKINS-13297 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13297 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: domi >Assignee: domi > > The order of the main sections of free and maven jobs are like this: > free > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4. Build Environment > 5. Build > 6. Post-build Actions > mvn > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4a Pre Steps > 4b Build > 4c Post Steps > 5. Build Settings > 6. Build Environment > 7. Post-build Actions > specially the 'Build Environment' seems to be placed at the wrong place for > the mvn job - because it is the setup of the job it feels more right to have > it at the start of the configuration (like in the free style job). > Why there is a 'Build Settings' section in the mvn job but not in the free > style job, I don't know... e.g. it contains 'E-mail Notification' which is > available in the 'Post-build Actions' of a freestyle job. -- 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
[JIRA] (JENKINS-13297) Make order of main sections the same between 'FreesytleJob' and 'Maven Job'
[ https://issues.jenkins-ci.org/browse/JENKINS-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161030#comment-161030 ] dogfood commented on JENKINS-13297: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #12|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/12/] [FIXED JENKINS-13297] Make order of main sections the same between 'FreesytleJob' and 'Maven Job' (Revision 98e75df11d2c574faca67e696ed75c477cb278ad) Result = SUCCESS imod : [98e75df11d2c574faca67e696ed75c477cb278ad|https://github.com/jenkinsci/jenkins/commit/98e75df11d2c574faca67e696ed75c477cb278ad] Files : * maven-plugin/src/main/resources/hudson/maven/MavenModuleSet/configure-entries.jelly > Make order of main sections the same between 'FreesytleJob' and 'Maven Job' > --- > > Key: JENKINS-13297 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13297 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: domi >Assignee: domi > > The order of the main sections of free and maven jobs are like this: > free > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4. Build Environment > 5. Build > 6. Post-build Actions > mvn > 1. Advanced Project Options > 2. Source Code Management > 3. Build Triggers > 4a Pre Steps > 4b Build > 4c Post Steps > 5. Build Settings > 6. Build Environment > 7. Post-build Actions > specially the 'Build Environment' seems to be placed at the wrong place for > the mvn job - because it is the setup of the job it feels more right to have > it at the start of the configuration (like in the free style job). > Why there is a 'Build Settings' section in the mvn job but not in the free > style job, I don't know... e.g. it contains 'E-mail Notification' which is > available in the 'Post-build Actions' of a freestyle job. -- 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
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161031#comment-161031 ] domi commented on JENKINS-13112: Anthony, I'm looking into the code and I'm still stuck, the main question which you still have not answered is: how do you add a 'post build step'? which section? which button? ... in the version you mention, this just does not exist! btw. Maven or FreeStyle Job? so where/how do you add such a post build action? please be more precise and as requested before, add screenshots which explain the whole configuration not just a snippet. > Adding any post-build step as a build step causes exception > --- > > Key: JENKINS-13112 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep > Environment: Windows Server 2008 >Reporter: Anthony Hartwig >Assignee: domi > Attachments: screenshot.jpg, Single step.jpg, stacktrace.txt > > > When attempting to add a post build step as a build step, then click save, an > exception is thrown. Stack trace attached. -- 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
[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)
[ https://issues.jenkins-ci.org/browse/JENKINS-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161032#comment-161032 ] gbois edited comment on JENKINS-13136 at 3/31/12 8:57 AM: -- Do you have news? was (Author: gbois): Do you have any new information? > Environment Variable Injection injecting (and overriding) unwanted variables > (ie JAVA_HOME) > --- > > Key: JENKINS-13136 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13136 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit > Slave Node: Windows XP > EnvInject: 1.38 >Reporter: Alex Gray >Assignee: gbois > Attachments: EnvInjectData.zip > > > We were using EnvInject 1.35 in various free-style jobs, but after we > upgraded to 1.36 jobs started failing. > This is the reason: > 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is > pointing to version 1.25. I can verify this by going to Jenkins->Manage > Jenkins->Manage Nodes->MyWinXPNode->"view log", and sure enough the node's > environment variables have JAVA_HOME pointing to 1.25 > 2) After upgraded to EnvInject 1.36, the jobs started failing because > JAVA_HOME has been overwritten to 1.27, which does not exist on the node. In > fact, I don't know where this is being set because the master does not have > java 1.27 either! > The only option that is is present in the job is this: > Inject environment variables to the build process > Properties Content: > TEMP=c:\\windows\\temp > TMP=c:\\windows\\temp > (everything else under "Inject Environment Variables" is blank. > I have not tried the latest version, 1.38, but I will, since all the jobs are > currently broken and I have nothing else to lose... > If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but > that does not work on multiconfiguration jobs. > I'll keep you posted. If this is fixed in 1.38, I will update this Jira. -- 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
[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)
[ https://issues.jenkins-ci.org/browse/JENKINS-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161032#comment-161032 ] gbois commented on JENKINS-13136: - Do you any new information? > Environment Variable Injection injecting (and overriding) unwanted variables > (ie JAVA_HOME) > --- > > Key: JENKINS-13136 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13136 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit > Slave Node: Windows XP > EnvInject: 1.38 >Reporter: Alex Gray >Assignee: gbois > Attachments: EnvInjectData.zip > > > We were using EnvInject 1.35 in various free-style jobs, but after we > upgraded to 1.36 jobs started failing. > This is the reason: > 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is > pointing to version 1.25. I can verify this by going to Jenkins->Manage > Jenkins->Manage Nodes->MyWinXPNode->"view log", and sure enough the node's > environment variables have JAVA_HOME pointing to 1.25 > 2) After upgraded to EnvInject 1.36, the jobs started failing because > JAVA_HOME has been overwritten to 1.27, which does not exist on the node. In > fact, I don't know where this is being set because the master does not have > java 1.27 either! > The only option that is is present in the job is this: > Inject environment variables to the build process > Properties Content: > TEMP=c:\\windows\\temp > TMP=c:\\windows\\temp > (everything else under "Inject Environment Variables" is blank. > I have not tried the latest version, 1.38, but I will, since all the jobs are > currently broken and I have nothing else to lose... > If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but > that does not work on multiconfiguration jobs. > I'll keep you posted. If this is fixed in 1.38, I will update this Jira. -- 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
[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)
[ https://issues.jenkins-ci.org/browse/JENKINS-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161032#comment-161032 ] gbois edited comment on JENKINS-13136 at 3/31/12 8:57 AM: -- Do you have any new information? was (Author: gbois): Do you any new information? > Environment Variable Injection injecting (and overriding) unwanted variables > (ie JAVA_HOME) > --- > > Key: JENKINS-13136 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13136 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit > Slave Node: Windows XP > EnvInject: 1.38 >Reporter: Alex Gray >Assignee: gbois > Attachments: EnvInjectData.zip > > > We were using EnvInject 1.35 in various free-style jobs, but after we > upgraded to 1.36 jobs started failing. > This is the reason: > 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is > pointing to version 1.25. I can verify this by going to Jenkins->Manage > Jenkins->Manage Nodes->MyWinXPNode->"view log", and sure enough the node's > environment variables have JAVA_HOME pointing to 1.25 > 2) After upgraded to EnvInject 1.36, the jobs started failing because > JAVA_HOME has been overwritten to 1.27, which does not exist on the node. In > fact, I don't know where this is being set because the master does not have > java 1.27 either! > The only option that is is present in the job is this: > Inject environment variables to the build process > Properties Content: > TEMP=c:\\windows\\temp > TMP=c:\\windows\\temp > (everything else under "Inject Environment Variables" is blank. > I have not tried the latest version, 1.38, but I will, since all the jobs are > currently broken and I have nothing else to lose... > If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but > that does not work on multiconfiguration jobs. > I'll keep you posted. If this is fixed in 1.38, I will update this Jira. -- 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
[JIRA] (JENKINS-13293) Add cron syntax to set Time Zone
[ https://issues.jenkins-ci.org/browse/JENKINS-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois updated JENKINS-13293: Component/s: core (was: buildresult-trigger) buildresult-trigger plugin delegates its cron expression value process to Jenkins core. Therefore it use the same behavior as other trigger such as SCMTrigger. Your issue is fine but it ties to core component. > Add cron syntax to set Time Zone > > > Key: JENKINS-13293 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13293 > Project: Jenkins > Issue Type: Improvement > Components: core >Reporter: Michael Haderman > > It would be nice to have the ability to set what time zone scheduled builds > should run in. > Common crontab syntax is > TZ=GMT > 30 11 * * * -- 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
[JIRA] (JENKINS-13204) Add "Poll Now" Feature
[ https://issues.jenkins-ci.org/browse/JENKINS-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois closed JENKINS-13204. --- Resolution: Postponed Thank you so much for your inputs. I'm choosing to postpone the issue resolution due to the Jenkins compatibility to Jenkins 1.410. > Add "Poll Now" Feature > -- > > Key: JENKINS-13204 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13204 > Project: Jenkins > Issue Type: New Feature > Components: scripttrigger >Affects Versions: current > Environment: Windows XP server 2003 >Reporter: pixman20 >Assignee: gbois >Priority: Minor > > It would be very useful to have a "Poll Now" feature that causes the script > trigger to begin polling. > As it is now, you must either wait or manually configure the project's > schedule to be sooner (and then change it back after testing). > The "Poll Now" feature is currently available for SCM triggers, and it should > work identically to that functionality. > The "Poll Now" option would go right above the "ScriptTrigger Log" option > with the same icon except with a little green play triangle (at least if the > goal is to match the SCM trigger mechanism identically). > Thanks! -- 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
[JIRA] (JENKINS-13268) Build hang
[ https://issues.jenkins-ci.org/browse/JENKINS-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois updated JENKINS-13268: Component/s: core (was: buildresult-trigger) > Build hang > -- > > Key: JENKINS-13268 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13268 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Coding Nerd > Attachments: Threadump.txt > > > I configure Jenkins to auto-install Ant 1.8.3 then execute the build. The > build hang after installing ant. -- 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
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161035#comment-161035 ] SCM/JIRA link daemon commented on JENKINS-13112: Code changed in jenkins User: imod Path: src/main/java/org/jenkinsci/plugins/conditionalbuildstep/ConditionalBuilder.java http://jenkins-ci.org/commit/conditional-buildstep-plugin/a13c4d9bc48e48557a76c379560ad9751af15b1d Log: [FIXED JENKINS-13112] Adding any post-build step as a build step causes exception Compare: https://github.com/jenkinsci/conditional-buildstep-plugin/compare/0c533f8...a13c4d9 > Adding any post-build step as a build step causes exception > --- > > Key: JENKINS-13112 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep > Environment: Windows Server 2008 >Reporter: Anthony Hartwig >Assignee: domi > Attachments: screenshot.jpg, Single step.jpg, stacktrace.txt > > > When attempting to add a post build step as a build step, then click save, an > exception is thrown. Stack trace attached. -- 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
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13112. Resolution: Fixed > Adding any post-build step as a build step causes exception > --- > > Key: JENKINS-13112 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep > Environment: Windows Server 2008 >Reporter: Anthony Hartwig >Assignee: domi > Attachments: screenshot.jpg, Single step.jpg, stacktrace.txt > > > When attempting to add a post build step as a build step, then click save, an > exception is thrown. Stack trace attached. -- 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
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161036#comment-161036 ] domi commented on JENKINS-13112: I think I finally figured you'r usecase - it it does not work, please open the issue again... > Adding any post-build step as a build step causes exception > --- > > Key: JENKINS-13112 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep > Environment: Windows Server 2008 >Reporter: Anthony Hartwig >Assignee: domi > Attachments: screenshot.jpg, Single step.jpg, stacktrace.txt > > > When attempting to add a post build step as a build step, then click save, an > exception is thrown. Stack trace attached. -- 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
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161036#comment-161036 ] domi edited comment on JENKINS-13112 at 3/31/12 9:30 AM: - I think I finally figured you'r usecase - if it does not work, please open the issue again... was (Author: domi): I think I finally figured you'r usecase - it it does not work, please open the issue again... > Adding any post-build step as a build step causes exception > --- > > Key: JENKINS-13112 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep > Environment: Windows Server 2008 >Reporter: Anthony Hartwig >Assignee: domi > Attachments: screenshot.jpg, Single step.jpg, stacktrace.txt > > > When attempting to add a post build step as a build step, then click save, an > exception is thrown. Stack trace attached. -- 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
[JIRA] (JENKINS-12250) Critical block can not be added into conditional step
[ https://issues.jenkins-ci.org/browse/JENKINS-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161037#comment-161037 ] domi commented on JENKINS-12250: it looks like you have not successfully installed the new version. It must be version 0.7-SNAPHSOT and not 0.6 You have to download the 'Exclusion-0.7-SNAPSHOT.hpi' anf install it via the advanced tap of the plugin manager at http://jenkinsServer/pluginManager/advanced > Critical block can not be added into conditional step > - > > Key: JENKINS-12250 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12250 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep, exclusion > Environment: Jenkins 1.445 > Jenkins Exclusion Plug-in 0.6 > conditional-buildstep 0.2 >Reporter: Oleksandr Popov >Assignee: Anthony Roux >Priority: Critical > Attachments: critical-block.PNG > > > I'm not able to add critical block into conditional step. See screen-shot for > details -- 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
[JIRA] (JENKINS-13289) Make 'Advanced' button collapsible
[ https://issues.jenkins-ci.org/browse/JENKINS-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161038#comment-161038 ] domi commented on JENKINS-13289: looks great! > Make 'Advanced' button collapsible > -- > > Key: JENKINS-13289 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13289 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: domi >Assignee: OHTAKE Tomohiro > > The 'Advanced' button in a configuration screen (jenkins/job/...) should be > collapsible again. > This would save space and make the UI more clean and intuitive. -- 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
[JIRA] (JENKINS-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe reassigned JENKINS-13238: Assignee: sogabe > Loading All Build History Fails > --- > > Key: JENKINS-13238 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: linux, jenkins 1.456 >Reporter: Spencer Oliver >Assignee: sogabe > > seems after the update from 1.455 to 1.456 causes an issue where pressing > 'More' to expand the job Build History now fails with a 404. > Calling the build history directly also causes the 404, eg. > http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ > For info rolling back to 1.455 cures the problem. > tested 1.457 and issue still present. > jenkins own server also shows the issue: > http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/ -- 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
[JIRA] (JENKINS-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13238. Resolution: Fixed > Loading All Build History Fails > --- > > Key: JENKINS-13238 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: linux, jenkins 1.456 >Reporter: Spencer Oliver >Assignee: sogabe > > seems after the update from 1.455 to 1.456 causes an issue where pressing > 'More' to expand the job Build History now fails with a 404. > Calling the build history directly also causes the 404, eg. > http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ > For info rolling back to 1.455 cures the problem. > tested 1.457 and issue still present. > jenkins own server also shows the issue: > http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/ -- 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
[JIRA] (JENKINS-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161039#comment-161039 ] SCM/JIRA link daemon commented on JENKINS-13238: Code changed in jenkins User: Seiji Sogabe Path: core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly http://jenkins-ci.org/commit/jenkins/a45ecf45ee8571aae7a0273784971afeeefb6e3c Log: [FIXED JENKINS-13238] Loading All Build History Fails > Loading All Build History Fails > --- > > Key: JENKINS-13238 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: linux, jenkins 1.456 >Reporter: Spencer Oliver >Assignee: sogabe > > seems after the update from 1.455 to 1.456 causes an issue where pressing > 'More' to expand the job Build History now fails with a 404. > Calling the build history directly also causes the 404, eg. > http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ > For info rolling back to 1.455 cures the problem. > tested 1.457 and issue still present. > jenkins own server also shows the issue: > http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/ -- 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
[JIRA] (JENKINS-13043) Test Results Trend graph missing intermittently
[ https://issues.jenkins-ci.org/browse/JENKINS-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161040#comment-161040 ] steven armstrong commented on JENKINS-13043: This is a big problem for us as we use jenkins to run lots of aat tests and our dashboard graphs keep dissapearing so the information displayed is not accurate. Any idea what the root cause is and wither this is an easy fix.. > Test Results Trend graph missing intermittently > --- > > Key: JENKINS-13043 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13043 > Project: Jenkins > Issue Type: Bug > Components: nunit >Affects Versions: current > Environment: Windows 2008R2 running Jenkins as a service. This isn't > an error, it's more of a bad state, so there's no stack trace to show. Here's > the /systemInfo dump: > Name Value > awt.toolkit sun.awt.windows.WToolkit > executable-war C:\Apps\Jenkins\jenkins.war > file.encoding Cp1252 > file.encoding.pkg sun.io > file.separator \ > hudson.diyChunking true > hudson.lifecycle hudson.lifecycle.WindowsServiceLifecycle > java.awt.graphicsenv sun.awt.Win32GraphicsEnvironment > java.awt.headless true > java.awt.printerjob sun.awt.windows.WPrinterJob > java.class.path C:\Apps\Jenkins\jenkins.war > java.class.version 50.0 > java.endorsed.dirs C:\Apps\Jenkins\jre\lib\endorsed > java.ext.dirs C:\Apps\Jenkins\jre\lib\ext;C:\Windows\Sun\Java\lib\ext > java.home C:\Apps\Jenkins\jre > java.io.tmpdir C:\Windows\TEMP\ > java.library.path > C:\Apps\Jenkins\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\csvn\bin\;C:\csvn\Python25\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program > Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft > SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL > Server\100\DTS\Binn\;c:\Program Files (x86)\Microsoft SQL > Server\100\Tools\Binn\VSShell\Common7\IDE\;c:\Program Files (x86)\Microsoft > SQL Server\100\DTS\Binn\;C:\Program Files\NCover\;C:\Program Files\Microsoft > Windows Performance Toolkit\;c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET > Web Pages\v1.0\;;. > java.runtime.name Java(TM) SE Runtime Environment > java.runtime.version 1.6.0_26-b03 > java.specification.name Java Platform API Specification > java.specification.vendor Sun Microsystems Inc. > java.specification.version 1.6 > java.vendor Sun Microsystems Inc. > java.vendor.url http://java.sun.com/ > java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi > java.version 1.6.0_26 > java.vm.info mixed mode > java.vm.name Java HotSpot(TM) Client VM > java.vm.specification.name Java Virtual Machine Specification > java.vm.specification.vendor Sun Microsystems Inc. > java.vm.specification.version 1.0 > java.vm.vendor Sun Microsystems Inc. > java.vm.version 20.1-b02 > line.separator > mail.smtp.sendpartial true > mail.smtps.sendpartial true > os.arch x86 > os.name Windows Server 2008 R2 > os.version 6.1 > path.separator ; > sun.arch.data.model 32 > sun.boot.class.path > C:\Apps\Jenkins\jre\lib\resources.jar;C:\Apps\Jenkins\jre\lib\rt.jar;C:\Apps\Jenkins\jre\lib\sunrsasign.jar;C:\Apps\Jenkins\jre\lib\jsse.jar;C:\Apps\Jenkins\jre\lib\jce.jar;C:\Apps\Jenkins\jre\lib\charsets.jar;C:\Apps\Jenkins\jre\lib\modules\jdk.boot.jar;C:\Apps\Jenkins\jre\classes > > sun.boot.library.path C:\Apps\Jenkins\jre\bin > sun.cpu.endian little > sun.cpu.isalist pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 > sun.desktop windows > sun.io.unicode.encoding UnicodeLittle > sun.java.command C:\Apps\Jenkins\jenkins.war --httpPort=8080 > sun.java.launcher SUN_STANDARD > sun.jnu.encoding Cp1252 > sun.management.compiler HotSpot Client Compiler > sun.os.patch.level Service Pack 1 > svnkit.http.methods Digest,Basic,NTLM,Negotiate > svnkit.ssh2.persistent false > user.country US > user.dir C:\Windows\system32 > user.home C:\ > user.language en > user.name $ > user.timezone America/Chicago > user.variant > Environment Variables > Name ↓ Value > ALLUSERSPROFILE C:\ProgramData > APPDATA C:\Windows\system32\config\systemprofile\AppData\Roaming > APR_ICONV1_PATH C:\csvn\bin\iconv\ > BASE C:\Apps\Jenkins > COMPUTERNAME 28SVMSVNCI051 > ComSpec C:\Windows\system32\cmd.exe > CommonProgramFiles C:\Program Files (x86)\Common Files > CommonProgramFiles(x86) C:\Program Files (x86)\Common Files > CommonProgramW6432 C:\Program Files\Common Files > FP_NO_HOST_CHECK NO > JAVA_HOME C:\Program Files (x86)\Java\jdk1.6.0_27 > JENKINS_HOME C:\Apps\Jenkins > LOCALAPPDATA C:\Windows\system32\config\systemprofile\AppData\Local > NUMBER_OF_PROCESSORS 2 > OS Windows_NT > PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WS
[JIRA] (JENKINS-9965) Nunit plugin does not display graph when fingerprinting is used on the xml report
[ https://issues.jenkins-ci.org/browse/JENKINS-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161041#comment-161041 ] steven armstrong commented on JENKINS-9965: --- is there any update on this has it been fixed in a later version of jenkins? > Nunit plugin does not display graph when fingerprinting is used on the xml > report > - > > Key: JENKINS-9965 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9965 > Project: Jenkins > Issue Type: Bug > Components: nunit > Environment: XP, all latest software versions as of 6/13/11 >Reporter: mark lemay >Assignee: redsolo > > Nunit plug-in does not display graph when fingerprinting is used on the xml > report -- 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
[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)
[ https://issues.jenkins-ci.org/browse/JENKINS-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161042#comment-161042 ] Alex Gray commented on JENKINS-13136: - Unfortunately no, except the problem is still there. I can reproduce it. We had some users report that the they are not using any environment injection options at all, and that their environment is still corrupt (the only clue is that they are using Perforce instead of SVN, but personally I don't think that is related). I cannot reproduce it on a clean Jenkins install too. There must be something in our environment that is causing this problem, or some other plugin that is interfering. I'm thinking about installing the latest version, since there is nothing to lose. I'm completely up for suggestions. I'm thinking about installing *all* the plugins of our production Jenkins on my test Jenkins to see if the problem occurs. > Environment Variable Injection injecting (and overriding) unwanted variables > (ie JAVA_HOME) > --- > > Key: JENKINS-13136 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13136 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit > Slave Node: Windows XP > EnvInject: 1.38 >Reporter: Alex Gray >Assignee: gbois > Attachments: EnvInjectData.zip > > > We were using EnvInject 1.35 in various free-style jobs, but after we > upgraded to 1.36 jobs started failing. > This is the reason: > 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is > pointing to version 1.25. I can verify this by going to Jenkins->Manage > Jenkins->Manage Nodes->MyWinXPNode->"view log", and sure enough the node's > environment variables have JAVA_HOME pointing to 1.25 > 2) After upgraded to EnvInject 1.36, the jobs started failing because > JAVA_HOME has been overwritten to 1.27, which does not exist on the node. In > fact, I don't know where this is being set because the master does not have > java 1.27 either! > The only option that is is present in the job is this: > Inject environment variables to the build process > Properties Content: > TEMP=c:\\windows\\temp > TMP=c:\\windows\\temp > (everything else under "Inject Environment Variables" is blank. > I have not tried the latest version, 1.38, but I will, since all the jobs are > currently broken and I have nothing else to lose... > If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but > that does not work on multiconfiguration jobs. > I'll keep you posted. If this is fixed in 1.38, I will update this Jira. -- 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
[JIRA] (JENKINS-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161043#comment-161043 ] dogfood commented on JENKINS-13238: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1625|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1625/] [FIXED JENKINS-13238] Loading All Build History Fails (Revision a45ecf45ee8571aae7a0273784971afeeefb6e3c) Result = SUCCESS Seiji Sogabe : [a45ecf45ee8571aae7a0273784971afeeefb6e3c|https://github.com/jenkinsci/jenkins/commit/a45ecf45ee8571aae7a0273784971afeeefb6e3c] Files : * core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly > Loading All Build History Fails > --- > > Key: JENKINS-13238 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: linux, jenkins 1.456 >Reporter: Spencer Oliver >Assignee: sogabe > > seems after the update from 1.455 to 1.456 causes an issue where pressing > 'More' to expand the job Build History now fails with a 404. > Calling the build history directly also causes the 404, eg. > http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ > For info rolling back to 1.455 cures the problem. > tested 1.457 and issue still present. > jenkins own server also shows the issue: > http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/ -- 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
[JIRA] (JENKINS-13220) The integration inconsistently handles change packages that are submitted but not yet accepted.
[ https://issues.jenkins-ci.org/browse/JENKINS-13220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161044#comment-161044 ] Cletus D'Souza commented on JENKINS-13220: -- If the new files are showing up in the 'si viewproject' output, then this would be a bug with the core Source product/api. Can you please check the 'si viewproject' output to see if this is the case? > The integration inconsistently handles change packages that are submitted but > not yet accepted. > --- > > Key: JENKINS-13220 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13220 > Project: Jenkins > Issue Type: Bug > Components: integrity-plugin >Affects Versions: current > Environment: Linux/x64. >Reporter: Eric Youngdale >Assignee: Cletus D'Souza > Labels: plugins > > We had an issue whereby there were a set of changes which were submitted but > not yet accepted into MKS Source. Some of the changes involved new source > files (JUnit tests in this case), and others involved changes to existing > files. > What I am seeing is that regarding changes to existing files, the plugin > correctly does not download them until the change package is eventually > accepted. However for any new files, this isn't the case - it downloads the > immediately no matter what the status of the change package. > In our case the new JUnit tests were being automatically run even though the > corresponding changes had not yet been applied and it caused the build to > fail. -- 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
[JIRA] (JENKINS-13221) The integration does not examine the filesystem to see if files in the workspace is missing.
[ https://issues.jenkins-ci.org/browse/JENKINS-13221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161045#comment-161045 ] Cletus D'Souza commented on JENKINS-13221: -- Seems like a reasonable request for providing a sandbox like functionality. Will consider this request for the next release of the plug-in > The integration does not examine the filesystem to see if files in the > workspace is missing. > > > Key: JENKINS-13221 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13221 > Project: Jenkins > Issue Type: Bug > Components: integrity-plugin >Affects Versions: current > Environment: Linux/x64 >Reporter: Eric Youngdale >Assignee: Cletus D'Souza > > Due to the extreme amount of time required to repopulate a workspace, we run > our Hudson build without doing a clean of the workspace with each build. > Thus in the normal case, we have a build run once an hour, it downloads all > changed files, and then it does the build. > But if a file in the workspace is missing or corrupt, it doesn't attempt to > re-download the file. Determining if the file is corrupt might be tricky (I > suppose one might store an MD5 sum in the local database for the workspace). > But when you have a file that is missing from the workspace, it ought to be a > no-brainer that the SCM plugin should download a new copy of the file. > I ran across this because I used this bug/feature as a workaround for this > issue: > https://issues.jenkins-ci.org/browse/JENKINS-13220 -- 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
[JIRA] (JENKINS-13298) Update JNA from version 3.3 to 3.4
Cory Downey created JENKINS-13298: -- Summary: Update JNA from version 3.3 to 3.4 Key: JENKINS-13298 URL: https://issues.jenkins-ci.org/browse/JENKINS-13298 Project: Jenkins Issue Type: Improvement Components: core Reporter: Cory Downey Priority: Minor Version 3.4 of JNA has been released. Jenkins is still packaging version 3.3. Version 3.4 added support for Linux on PowerPC platform. I have replaced the JNA 3.3 jar in WEB-INF/lib with JNA 3.4 with no issues. -- 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
[JIRA] (JENKINS-13242) Email Extension plugin - groovy and jelly do not update $rooturl after Jenkins URL updated
[ https://issues.jenkins-ci.org/browse/JENKINS-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinsato reassigned JENKINS-13242: -- Assignee: shinsato > Email Extension plugin - groovy and jelly do not update $rooturl after > Jenkins URL updated > -- > > Key: JENKINS-13242 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13242 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Windows 2008 R2 >Reporter: shinsato >Assignee: shinsato > > Running the Email Extension plugin - version 2.14.1 with Jenkins 1.424.6 - I > had the Jenkins URL set incorrectly which was causing broken images and the > wrong rooturl in my email-ext status message after a job built (using the > HTML and the included templates). Fixing the Jenkins URL did not fix it. I > then upgraded to Email-ext version 2.19 with Jenkins 1.457. This also did not > fix it. I'm confused because if I "echo %rooturl%" as a Windows Batch script > as a build step - it gives the right response. I can't see any place that the > plugin could be caching this info. -- 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
[JIRA] (JENKINS-13242) Email Extension plugin - groovy and jelly do not update $rooturl after Jenkins URL updated
[ https://issues.jenkins-ci.org/browse/JENKINS-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinsato resolved JENKINS-13242. Fix Version/s: current Resolution: Fixed This will be released with 2.20. > Email Extension plugin - groovy and jelly do not update $rooturl after > Jenkins URL updated > -- > > Key: JENKINS-13242 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13242 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Windows 2008 R2 >Reporter: shinsato >Assignee: shinsato > Fix For: current > > > Running the Email Extension plugin - version 2.14.1 with Jenkins 1.424.6 - I > had the Jenkins URL set incorrectly which was causing broken images and the > wrong rooturl in my email-ext status message after a job built (using the > HTML and the included templates). Fixing the Jenkins URL did not fix it. I > then upgraded to Email-ext version 2.19 with Jenkins 1.457. This also did not > fix it. I'm confused because if I "echo %rooturl%" as a Windows Batch script > as a build step - it gives the right response. I can't see any place that the > plugin could be caching this info. -- 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
[JIRA] (JENKINS-12042) SVN_REVISION varable is empty if URL contains "@Revision"
[ https://issues.jenkins-ci.org/browse/JENKINS-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161047#comment-161047 ] OHTAKE Tomohiro commented on JENKINS-12042: --- The issue has been fixed in 1.32. (JENKINS-10942) Could you post the output of 'env | grep SVN' with/without @Revision ? > SVN_REVISION varable is empty if URL contains "@Revision" > - > > Key: JENKINS-12042 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12042 > Project: Jenkins > Issue Type: Bug > Components: core, subversion > Environment: Jenkins 1.442 > Subversion plugin 1.37 >Reporter: Oleksandr Popov >Priority: Blocker > > SVN_REVISION variable is not set if I specify revision (or keyword like HEAD) > in URL (like @123). -- 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
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro resolved JENKINS-12994. --- Resolution: Fixed > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo >Priority: Critical > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- 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
[JIRA] (JENKINS-11375) Provide Clearcase changed files to email-ext standard HTML jelly template
[ https://issues.jenkins-ci.org/browse/JENKINS-11375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161048#comment-161048 ] SCM/JIRA link daemon commented on JENKINS-11375: Code changed in jenkins User: Krzysztof Malinowski Path: src/main/java/hudson/plugins/clearcase/ClearCaseChangeLogEntry.java src/test/java/hudson/plugins/clearcase/ClearCaseChangeLogEntryTest.java http://jenkins-ci.org/commit/clearcase-plugin/7eea44105c70f26f885f20a124e67915e9ca8ccd Log: Implemented getAffectedFiles for use with email-ext HTML jelly template Issue #JENKINS-11375 - Provide Clearcase changed files to email-ext standard HTML jelly template > Provide Clearcase changed files to email-ext standard HTML jelly template > - > > Key: JENKINS-11375 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11375 > Project: Jenkins > Issue Type: Improvement > Components: clearcase > Environment: Jenkins 1.432, Clearcase plugin 1.3.6, email-ext 2.15 >Reporter: Krzysztof Malinowski >Assignee: Krzysztof Malinowski >Priority: Minor > > email-ext's standard HTML jelly template uses getAffectedFiles method for > changed files in email. This interface was introduced some time ago and > Clearcase plugin does not currently implement it. The change is simple yet it > allows to receive list of changed files in standard jelly html email from > email-ext, which is otherwise empty. -- 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
F ind no com mitme nt aff airs. Larg est casu al en counters si te. No ris k to jo in.
F ind no com mitme nt aff airs. Larg est casu al en counters si te. No ris k to jo in. http://fc.cx/h - If you would like to not be contacted from us in the future please email us at: newburycor [at] gmail [dot] com Or write to: P.O. Box 191, 62 Street, Vancouver, Canada
[JIRA] (JENKINS-12522) Deploy artifacts for failed builds, too
[ https://issues.jenkins-ci.org/browse/JENKINS-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161049#comment-161049 ] SCM/JIRA link daemon commented on JENKINS-12522: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/artifactdeployer/ArtifactDeployerPublisher.java src/main/resources/org/jenkinsci/plugins/artifactdeployer/ArtifactDeployerPublisher/config.jelly http://jenkins-ci.org/commit/artifactdeployer-plugin/f6308fac57a39d2e82a86380d9666c2d3dbe6f4e Log: Fix JENKINS-12522 > Deploy artifacts for failed builds, too > --- > > Key: JENKINS-12522 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12522 > Project: Jenkins > Issue Type: Improvement > Components: artifactdeployer >Affects Versions: current >Reporter: Dirk Kuypers >Assignee: gbois > Labels: deployment > > I took the description below from the plugin Wiki because I have a similar > problem. I need to archive all unit test logs for our QA after running a unit > test project even if some tests fail without cluttering my Jenkins with > hundreds of build logs. > Original problem from the Wiki: > My Jenkins job has the following build steps: > 1. Execute Windows batch command (a set of simple commands terminated by an > 'exit X' statement, where X can be zero for successful builds and non-zero > for failed builds) > 2. Deploy artifacts from workspace to remote directories > If the exit statement at the end of my batch commands is non-zero then the > artifacts are NOT deployed. I would like to be able to deploy artifacts > following a failed build because although the build failed there will be > build log files indicating the reason for failure as well as partial > artifacts. -- 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
[JIRA] (JENKINS-8682) Disable polling if build is running
[
https://issues.jenkins-ci.org/browse/JENKINS-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161050#comment-161050
]
SCM/JIRA link daemon commented on JENKINS-8682:
---
Code changed in jenkins
User: Vincent Latombe
Path:
src/main/java/hudson/plugins/clearcase/AbstractClearCaseScm.java
http://jenkins-ci.org/commit/clearcase-plugin/d6a013dc0ca1858a8ab2b262159a8154428550f6
Log:
[FIX JENKINS-8682]: check if build is running
Based on anb0s's work, do not prevent polling if job can be executed
concurrently.
> Disable polling if build is running
> ---
>
> Key: JENKINS-8682
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8682
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase, core
>Affects Versions: current
> Environment: Windows XP, Hudson 1.395, CC Plugin 1.3.5
>Reporter: anb0s
>Assignee: Vincent Latombe
>
> {color:red}DUPLICATE: http://issues.hudson-ci.org/browse/HUDSON-8674*{color}
> We enabled minutely SCM polling. If build is running (about 2 hours) we see
> lots of polling executions (lshistory). This slow down the proccess. It
> should be possible to disable polling if build is running.
--
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
[JIRA] (JENKINS-9630) ClearCase Plugin: SCM Polling Branch System-Level Config Setting Does Not Work
[ https://issues.jenkins-ci.org/browse/JENKINS-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe closed JENKINS-9630. > ClearCase Plugin: SCM Polling Branch System-Level Config Setting Does Not Work > -- > > Key: JENKINS-9630 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9630 > Project: Jenkins > Issue Type: Bug > Environment: Hudson/Jenkins 1.395 and up >Reporter: mlumsde >Assignee: Vincent Latombe >Priority: Critical > > While upgrading to latest version of the ClearCase plugin, we noticed that > the system-level configuration (via "Configure Jenkins") no longer honors the > SCM Polling Branch we used to define there for ClearCase. > Since our group has well over 100+ jobs, many of which were dependent upon > this "master" setting, the loss of this configuration setting makes > maintenance as branch names change a nightmare. -- 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
[JIRA] (JENKINS-9631) ClearCase Plugin: SCM Polling Branch System-Level Config Setting Does Not Work
[ https://issues.jenkins-ci.org/browse/JENKINS-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe closed JENKINS-9631. > ClearCase Plugin: SCM Polling Branch System-Level Config Setting Does Not Work > -- > > Key: JENKINS-9631 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9631 > Project: Jenkins > Issue Type: Bug > Environment: Hudson/Jenkins 1.395 and up >Reporter: mlumsde >Assignee: Vincent Latombe >Priority: Critical > > While upgrading to latest version of the ClearCase plugin, we noticed that > the system-level configuration (via "Configure Jenkins") no longer honors the > SCM Polling Branch we used to define there for ClearCase. > Since our group has well over 100+ jobs, many of which were dependent upon > this "master" setting, the loss of this configuration setting makes > maintenance as branch names change a nightmare. -- 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
[JIRA] (JENKINS-7122) Disable lshistory
[ https://issues.jenkins-ci.org/browse/JENKINS-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe closed JENKINS-7122. > Disable lshistory > -- > > Key: JENKINS-7122 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7122 > Project: Jenkins > Issue Type: Improvement > Components: clearcase >Affects Versions: current >Reporter: Jose Sa >Assignee: Vincent Latombe >Priority: Critical > > Using the corrent method for Change detection (lshistory) works when the > config spec is based on some branch/LATEST rules, which is the correct > settings for Continuous Integration. > However for maintenance projects where the Config Spec is based on specific > LABELS the lshistory is not adequate since the LATEST changes in the branch > may not reflect the changes made on the config spec used since last build. > Therefore there should be also the option to disable any change detection > (disable run lshistory), unless of course you know some other way of trackign > changes on builds based on Floating Labels. -- 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
[JIRA] (JENKINS-12522) Deploy artifacts for failed builds, too
[ https://issues.jenkins-ci.org/browse/JENKINS-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-12522. - Resolution: Fixed > Deploy artifacts for failed builds, too > --- > > Key: JENKINS-12522 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12522 > Project: Jenkins > Issue Type: Improvement > Components: artifactdeployer >Affects Versions: current >Reporter: Dirk Kuypers >Assignee: gbois > Labels: deployment > > I took the description below from the plugin Wiki because I have a similar > problem. I need to archive all unit test logs for our QA after running a unit > test project even if some tests fail without cluttering my Jenkins with > hundreds of build logs. > Original problem from the Wiki: > My Jenkins job has the following build steps: > 1. Execute Windows batch command (a set of simple commands terminated by an > 'exit X' statement, where X can be zero for successful builds and non-zero > for failed builds) > 2. Deploy artifacts from workspace to remote directories > If the exit statement at the end of my batch commands is non-zero then the > artifacts are NOT deployed. I would like to be able to deploy artifacts > following a failed build because although the build failed there will be > build log files indicating the reason for failure as well as partial > artifacts. -- 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
[JIRA] (JENKINS-8682) Disable polling if build is running
[
https://issues.jenkins-ci.org/browse/JENKINS-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161051#comment-161051
]
dogfood commented on JENKINS-8682:
--
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_clearcase #75|http://ci.jenkins-ci.org/job/plugins_clearcase/75/]
[FIX JENKINS-8682]: check if build is running (Revision
d6a013dc0ca1858a8ab2b262159a8154428550f6)
Result = SUCCESS
Vincent Latombe :
Files :
* src/main/java/hudson/plugins/clearcase/AbstractClearCaseScm.java
> Disable polling if build is running
> ---
>
> Key: JENKINS-8682
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8682
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase, core
>Affects Versions: current
> Environment: Windows XP, Hudson 1.395, CC Plugin 1.3.5
>Reporter: anb0s
>Assignee: Vincent Latombe
>
> {color:red}DUPLICATE: http://issues.hudson-ci.org/browse/HUDSON-8674*{color}
> We enabled minutely SCM polling. If build is running (about 2 hours) we see
> lots of polling executions (lshistory). This slow down the proccess. It
> should be possible to disable polling if build is running.
--
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
[JIRA] (JENKINS-12565) maven 2/3 job automatically archives the artifact(s) but without the "archive artifacts checkbox" and a pattern post build deploy to fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois closed JENKINS-12565. --- Resolution: Won't Fix ArtifactDeployer will not be aware of automatic Maven2 archiving > maven 2/3 job automatically archives the artifact(s) but without the "archive > artifacts checkbox" and a pattern post build deploy to fails > -- > > Key: JENKINS-12565 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12565 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer, core, deploy, maven2 > Environment: Jenkins 1.446 > master on rhel 6 x64 running as a service via the wrapper > slave on windows 2k3 running as a service controlled by master > build job configured as a maven2/3 project >Reporter: sbrinkmeyer >Assignee: gbois >Priority: Minor > Labels: artifact, deployment, jenkins, maven > Attachments: log and config.zip > > > created a new maven 2/3 job that runs maven up to install, used the post > build check box of deploy. on the master i can see the artifacts are > auto-archived. but the post build deploy step is not using these > auto-archived [j|e|w]ar files and or using the maven logic to determine what > the deployable files should be. > the files are archived on master at > jenkins/data/jobs/jobname/buildid/mavenmoduelnames/ as links to > jenkins/data/jobs/jobname/modules/mavenmodulename/builds/buildid/archive/... > i know the master has the files, it just is failing the deploy because the > checkbox is not selected -- 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
[JIRA] (JENKINS-11867) Deployed files have a different time with original files.
[ https://issues.jenkins-ci.org/browse/JENKINS-11867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161053#comment-161053 ] SCM/JIRA link daemon commented on JENKINS-11867: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/artifactdeployer/service/LocalCopy.java http://jenkins-ci.org/commit/artifactdeployer-plugin/69dbb8fd8836100996f759d690e1e1be9b989d3e Log: Fix JENKINS-11867 > Deployed files have a different time with original files. > - > > Key: JENKINS-11867 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11867 > Project: Jenkins > Issue Type: Improvement > Components: artifactdeployer >Affects Versions: current > Environment: Windows Server 2008 using Console >Reporter: xster >Assignee: gbois > Labels: jenkins, plugin > > Deployed files have the time of deployment. > I prefer original file time. -- 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
[JIRA] (JENKINS-11867) Deployed files have a different time with original files.
[ https://issues.jenkins-ci.org/browse/JENKINS-11867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-11867. - Resolution: Fixed Sorry for this late fix. Available in 0.15 > Deployed files have a different time with original files. > - > > Key: JENKINS-11867 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11867 > Project: Jenkins > Issue Type: Improvement > Components: artifactdeployer >Affects Versions: current > Environment: Windows Server 2008 using Console >Reporter: xster >Assignee: gbois > Labels: jenkins, plugin > > Deployed files have the time of deployment. > I prefer original file time. -- 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
[JIRA] (JENKINS-10077) archiving large files takes extrordinarily long time
[ https://issues.jenkins-ci.org/browse/JENKINS-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois closed JENKINS-10077. --- Resolution: Won't Fix Unfortunately, I can't fix this issue. If in your context it is slow, I suggest you should switch to an another alternative (other plugin maybe, a simple script called for example with the post-build-script plugin and so on). > archiving large files takes extrordinarily long time > > > Key: JENKINS-10077 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10077 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer >Affects Versions: current > Environment: Mac OS 10.6.7, Xserve Dual 2.8 Ghz Intel Xeon, 2 TB HDD > RAID-1 >Reporter: Jarom Loveridge >Assignee: gbois >Priority: Critical > Attachments: threads.log > > > We have a project that creates a 3.2 GB file that needs to be archived. We > are currently running Jenkins 1.417. The building of the project works just > fine but when the archival step begins the process takes forever. I allowed > the job to run for more than 12 hours and the archive never completed. > I can manually copy the files in a fraction of the time (only a few minutes > for a build directory of over 15 GB). Increasing the amount of memory > available to Jenkins does not improve the copy performance. While the files > are being archived the java process takes 100% of the processor cycles on a > single processor core. Memory usage does not increase significantly > regardless of the number or size of the files to be archived. And disk > utilization during the archival process is unbelievably low as well. -- 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
[JIRA] (JENKINS-11824) Can't use a env parameter for "Stream selector" when recommended baseline is selected (fix attached)
[
https://issues.jenkins-ci.org/browse/JENKINS-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161055#comment-161055
]
SCM/JIRA link daemon commented on JENKINS-11824:
Code changed in jenkins
User: Vincent Latombe
Path:
src/main/java/hudson/plugins/clearcase/ucm/UcmMakeBaseline.java
http://jenkins-ci.org/commit/clearcase-plugin/4482660f2a39a366de77c401df623fddfc9bbd3e
Log:
[FIX JENKINS-11824] Can't use a env parameter for "Stream
selector" when recommended baseline is selected
https://issues.jenkins-ci.org/browse/JENKINS-11824
> Can't use a env parameter for "Stream selector" when recommended baseline is
> selected (fix attached)
>
>
> Key: JENKINS-11824
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11824
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase
>Affects Versions: current
> Environment: Windows XP
>Reporter: Tim Dossett
>Assignee: Vincent Latombe
>Priority: Minor
> Fix For: current
>
>
> Using the env parameter "Parent_Stream" for the "Stream selector" when making
> recommended baseline results in an error:
> cleartool chstream -rec -def ${Parent_Stream}
> cleartool: Error: Unable to determine VOB for pathname ".".
> cleartool: Error: Unable to find stream "${Parent_Stream}".
> Fix to expand the env variable for the make recommended baseline command:
> UcmMakeBaseline.java, about line 305:
> was:recommendBaseline(clearTool, ucm.getStream());
> now:recommendBaseline(clearTool, Util.replaceMacro(ucm.getStream(),
> variableResolver) );
--
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
[JIRA] (JENKINS-8497) Ability to use job parameter in all configuration fields (i.e. load rules)
[ https://issues.jenkins-ci.org/browse/JENKINS-8497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe closed JENKINS-8497. > Ability to use job parameter in all configuration fields (i.e. load rules) > -- > > Key: JENKINS-8497 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8497 > Project: Jenkins > Issue Type: Improvement > Components: clearcase >Affects Versions: current >Reporter: jacaru >Assignee: Vincent Latombe >Priority: Minor > Attachments: > 0001-HUDSON-8497-Ability-to-use-job-parameter-in-all-conf.patch > > > Ability to use job parameters in all configuration fields. For example, they > can be used in view path but they can't be used in load rules. -- 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
[JIRA] (JENKINS-5227) Add an option to override the 'cleartool' location for slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe closed JENKINS-5227. > Add an option to override the 'cleartool' location for slaves > - > > Key: JENKINS-5227 > URL: https://issues.jenkins-ci.org/browse/JENKINS-5227 > Project: Jenkins > Issue Type: Improvement > Components: clearcase >Reporter: Romain Seguy >Assignee: Vincent Latombe > Attachments: clearcase-1.0.2-bib.zip > > > The 'cleartool' location is currently global to the whole Hudson instance: It > can't be configured differently when running a job on a slave on which CC is > not installed in the same place as the master. -- 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
[JIRA] (JENKINS-11824) Can't use a env parameter for "Stream selector" when recommended baseline is selected (fix attached)
[
https://issues.jenkins-ci.org/browse/JENKINS-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161057#comment-161057
]
dogfood commented on JENKINS-11824:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_clearcase #77|http://ci.jenkins-ci.org/job/plugins_clearcase/77/]
[FIX JENKINS-11824] Can't use a env parameter for "Stream (Revision
4482660f2a39a366de77c401df623fddfc9bbd3e)
Result = SUCCESS
Vincent Latombe :
Files :
* src/main/java/hudson/plugins/clearcase/ucm/UcmMakeBaseline.java
> Can't use a env parameter for "Stream selector" when recommended baseline is
> selected (fix attached)
>
>
> Key: JENKINS-11824
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11824
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase
>Affects Versions: current
> Environment: Windows XP
>Reporter: Tim Dossett
>Assignee: Vincent Latombe
>Priority: Minor
> Fix For: current
>
>
> Using the env parameter "Parent_Stream" for the "Stream selector" when making
> recommended baseline results in an error:
> cleartool chstream -rec -def ${Parent_Stream}
> cleartool: Error: Unable to determine VOB for pathname ".".
> cleartool: Error: Unable to find stream "${Parent_Stream}".
> Fix to expand the env variable for the make recommended baseline command:
> UcmMakeBaseline.java, about line 305:
> was:recommendBaseline(clearTool, ucm.getStream());
> now:recommendBaseline(clearTool, Util.replaceMacro(ucm.getStream(),
> variableResolver) );
--
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
[JIRA] (JENKINS-13215) NullPointerException when Category have value : not selected
[
https://issues.jenkins-ci.org/browse/JENKINS-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161058#comment-161058
]
SCM/JIRA link daemon commented on JENKINS-13215:
Code changed in jenkins
User: Seiji Sogabe
Path:
src/main/java/hudson/plugins/mantis/MantisIssueRegister.java
src/main/java/hudson/plugins/mantis/soap/mantis110/MantisSessionImpl.java
src/main/java/hudson/plugins/mantis/soap/mantis120/MantisSessionImpl.java
http://jenkins-ci.org/commit/mantis-plugin/b8b2540185c51f50c93537ac36304a5185e544b9
Log:
[FIXED JENKINS-13215] NullPointerException when Category have value : not
selected.
> NullPointerException when Category have value : not selected
>
>
> Key: JENKINS-13215
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13215
> Project: Jenkins
> Issue Type: Bug
> Components: mantis
>Affects Versions: current
> Environment: Debian x64
>Reporter: Sébastien Heurtematte
>Assignee: sogabe
>
> In the project configuration of a job, when you don't select Mantis Project
> and/or Category.
> and choose to activate the option : "File a ticket to Mantis"
> a NullPointerException is thrown
> java.lang.NullPointerException
> at
> hudson.plugins.mantis.soap.mantis120.MantisSessionImpl.addIssue(MantisSessionImpl.java:134)
> at hudson.plugins.mantis.MantisSite.addIssue(MantisSite.java:173)
> at
> hudson.plugins.mantis.MantisIssueRegister.perform(MantisIssueRegister.java:74)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.ivy.IvyModuleSetBuild$RunnerImpl.post2(IvyModuleSetBuild.java:587)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> The problem become from the class : MantisIssueRegister.createIssue
> Where this test exist :
> if (projectId == MantisProject.NONE ||
> MantisCategory.None.equals(categoryName)) {
> return null;
> }
> Is it possible to have just a log message maybe first.
> And after, a required field on project configuration and the ability to have
> category field : not selected
> if there is no impact on the rest of the plugin.
--
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
[JIRA] (JENKINS-13215) NullPointerException when Category have value : not selected
[
https://issues.jenkins-ci.org/browse/JENKINS-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-13215.
Resolution: Fixed
> NullPointerException when Category have value : not selected
>
>
> Key: JENKINS-13215
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13215
> Project: Jenkins
> Issue Type: Bug
> Components: mantis
>Affects Versions: current
> Environment: Debian x64
>Reporter: Sébastien Heurtematte
>Assignee: sogabe
>
> In the project configuration of a job, when you don't select Mantis Project
> and/or Category.
> and choose to activate the option : "File a ticket to Mantis"
> a NullPointerException is thrown
> java.lang.NullPointerException
> at
> hudson.plugins.mantis.soap.mantis120.MantisSessionImpl.addIssue(MantisSessionImpl.java:134)
> at hudson.plugins.mantis.MantisSite.addIssue(MantisSite.java:173)
> at
> hudson.plugins.mantis.MantisIssueRegister.perform(MantisIssueRegister.java:74)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.ivy.IvyModuleSetBuild$RunnerImpl.post2(IvyModuleSetBuild.java:587)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> The problem become from the class : MantisIssueRegister.createIssue
> Where this test exist :
> if (projectId == MantisProject.NONE ||
> MantisCategory.None.equals(categoryName)) {
> return null;
> }
> Is it possible to have just a log message maybe first.
> And after, a required field on project configuration and the ability to have
> category field : not selected
> if there is no impact on the rest of the plugin.
--
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
[JIRA] (JENKINS-13215) NullPointerException when Category have value : not selected
[
https://issues.jenkins-ci.org/browse/JENKINS-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161059#comment-161059
]
dogfood commented on JENKINS-13215:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_mantis
#56|http://ci.jenkins-ci.org/job/plugins_mantis/56/]
[FIXED JENKINS-13215] NullPointerException when Category have value : not
selected. (Revision b8b2540185c51f50c93537ac36304a5185e544b9)
Result = SUCCESS
Seiji Sogabe :
Files :
* src/main/java/hudson/plugins/mantis/soap/mantis120/MantisSessionImpl.java
* src/main/java/hudson/plugins/mantis/MantisIssueRegister.java
* src/main/java/hudson/plugins/mantis/soap/mantis110/MantisSessionImpl.java
> NullPointerException when Category have value : not selected
>
>
> Key: JENKINS-13215
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13215
> Project: Jenkins
> Issue Type: Bug
> Components: mantis
>Affects Versions: current
> Environment: Debian x64
>Reporter: Sébastien Heurtematte
>Assignee: sogabe
>
> In the project configuration of a job, when you don't select Mantis Project
> and/or Category.
> and choose to activate the option : "File a ticket to Mantis"
> a NullPointerException is thrown
> java.lang.NullPointerException
> at
> hudson.plugins.mantis.soap.mantis120.MantisSessionImpl.addIssue(MantisSessionImpl.java:134)
> at hudson.plugins.mantis.MantisSite.addIssue(MantisSite.java:173)
> at
> hudson.plugins.mantis.MantisIssueRegister.perform(MantisIssueRegister.java:74)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.ivy.IvyModuleSetBuild$RunnerImpl.post2(IvyModuleSetBuild.java:587)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> The problem become from the class : MantisIssueRegister.createIssue
> Where this test exist :
> if (projectId == MantisProject.NONE ||
> MantisCategory.None.equals(categoryName)) {
> return null;
> }
> Is it possible to have just a log message maybe first.
> And after, a required field on project configuration and the ability to have
> category field : not selected
> if there is no impact on the rest of the plugin.
--
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
[JIRA] (JENKINS-12825) Allow expansion of environment variables in the configuration
[ https://issues.jenkins-ci.org/browse/JENKINS-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161060#comment-161060 ] Zachary Young commented on JENKINS-12825: - I would like to see this also, with variable expansion in the list of WAR/EAR files to be deployed such that it handles a list like 'foo.war, , baz.war' correctly (the list in the configuration being '$deploy_foo, $deploy_bar, $deploy_baz', and the user chose to leave the '$deploy_bar' variable empty to omit it from the deployment). > Allow expansion of environment variables in the configuration > - > > Key: JENKINS-12825 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12825 > Project: Jenkins > Issue Type: New Feature > Components: deploy >Reporter: hand_of_henry > > Ahoy, > I'm creating a deployment build that's parameterized with a "Choice" pull > down list. The goal is to deploy the war to the IP address specified by the > build parameter. Currently the form fields do not resolve environment > variables so the IP Address is never expanded to the selected value. > I've tested this with a Tomcat 7 deploy and eyeballed the code and I don't > see any resolving for any of the Tomcat Deployment Containers. > I think this would be nice. > Thanks, > Brian -- 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
[JIRA] (JENKINS-13192) groovy template meets error when there are git changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161061#comment-161061 ] Larry Cai commented on JENKINS-13192: - Haha, ok, fixed now. See pull request https://github.com/jenkinsci/email-ext-plugin/pull/36 > groovy template meets error when there are git changes > -- > > Key: JENKINS-13192 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13192 > Project: Jenkins > Issue Type: Bug > Components: email-ext > Environment: ubuntu 11.10/openjdk/jenkins1.452/git >Reporter: Larry Cai >Priority: Minor > > groovy template had some errors for html/txt report when it has git changes, > I didn't check for svn/cvs > Following varible doesn't recognize inside groovy > - cs.hudsonUser (no husdonUser for changeSet class, it just error instead of > return nil) > - cs.changeNumber (does it work for cvs or svn ?) > Since I don't know the background and other environment (cvs/svn), I can't > provide complete patch > rgs/larry -- 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
[JIRA] (JENKINS-13192) groovy template meets error when there are git changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161062#comment-161062 ] SCM/JIRA link daemon commented on JENKINS-13192: Code changed in jenkins User: Larry Cai Path: src/main/resources/hudson/plugins/emailext/templates/groovy-html.template http://jenkins-ci.org/commit/email-ext-plugin/4c16db3144bd23fcacbc3f12ebd8611eddfc9f3c Log: Fix JENKINS-13192 - husdonUser doesn't exist, use author directly - changeNumber doesn't exist, add check whether the property exist, otherwise show space - msgAnnotated doesn't exist for it, change to cs all those parameters need to check in ChangeLogSet or inherited class > groovy template meets error when there are git changes > -- > > Key: JENKINS-13192 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13192 > Project: Jenkins > Issue Type: Bug > Components: email-ext > Environment: ubuntu 11.10/openjdk/jenkins1.452/git >Reporter: Larry Cai >Priority: Minor > > groovy template had some errors for html/txt report when it has git changes, > I didn't check for svn/cvs > Following varible doesn't recognize inside groovy > - cs.hudsonUser (no husdonUser for changeSet class, it just error instead of > return nil) > - cs.changeNumber (does it work for cvs or svn ?) > Since I don't know the background and other environment (cvs/svn), I can't > provide complete patch > rgs/larry -- 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
[JIRA] (JENKINS-13192) groovy template meets error when there are git changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161063#comment-161063 ] SCM/JIRA link daemon commented on JENKINS-13192: Code changed in jenkins User: slide Path: src/main/resources/hudson/plugins/emailext/templates/groovy-html.template http://jenkins-ci.org/commit/email-ext-plugin/552bd6c80ca85c3b288abf338ef7ce7275e42247 Log: Merge pull request #36 from larrycai/master Bug fix for JENKINS-13192 Compare: https://github.com/jenkinsci/email-ext-plugin/compare/5b20b8e...552bd6c > groovy template meets error when there are git changes > -- > > Key: JENKINS-13192 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13192 > Project: Jenkins > Issue Type: Bug > Components: email-ext > Environment: ubuntu 11.10/openjdk/jenkins1.452/git >Reporter: Larry Cai >Priority: Minor > > groovy template had some errors for html/txt report when it has git changes, > I didn't check for svn/cvs > Following varible doesn't recognize inside groovy > - cs.hudsonUser (no husdonUser for changeSet class, it just error instead of > return nil) > - cs.changeNumber (does it work for cvs or svn ?) > Since I don't know the background and other environment (cvs/svn), I can't > provide complete patch > rgs/larry -- 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
