[JIRA] (JENKINS-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158648#comment-158648 ] Oleksandr Popov commented on JENKINS-12113: --- @kutzi - Any updates or estimates? > Maven - java.io.IOException: error=2, No such file or directory if in SVN > configuration parameters used in Local module directory section > - > > Key: JENKINS-12113 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 > Project: Jenkins > Issue Type: Bug > Components: core, maven, parameters, subversion > Environment: Jenkins 1.448 > Subversion Plugin 1.37 > Maven Integration Plugin 1.448 > Ant 1.1 >Reporter: Oleksandr Popov >Assignee: kutzi >Priority: Blocker > Attachments: svn_maven_issue_01.PNG, svn_maven_issue_02.PNG > > > Maven is unable to work if in Subversion configuration parameters are used in > Local module directory section. > As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in > Local module directory section. And when I run it - Maven failed > (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-12648) TestNG 0.31 does not show test results when tests failed
Peter Lustig created JENKINS-12648: -- Summary: TestNG 0.31 does not show test results when tests failed Key: JENKINS-12648 URL: https://issues.jenkins-ci.org/browse/JENKINS-12648 Project: Jenkins Issue Type: Bug Components: testng Affects Versions: current Reporter: Peter Lustig Assignee: nalin_makar Priority: Critical Whenever I use the TestNG-Plugin 0.31 it only shows reports if the tests passed. But if the failey there are no test results. If I downgrade to 0.26 for example everthing works fine. Both the failed and passed test results are displayed. Please fix this, would be very important. Thank you! -- 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-12079) Support master / slave usage
[ https://issues.jenkins-ci.org/browse/JENKINS-12079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158649#comment-158649 ] Thomas Fields commented on JENKINS-12079: - Hi, I'm using Jenkins ver. 1.439 Regards, Tom. > Support master / slave usage > > > Key: JENKINS-12079 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12079 > Project: Jenkins > Issue Type: Bug > Components: locked-files-report >Affects Versions: current >Reporter: Thomas Fields >Assignee: redsolo > > Hi, > Does this plugin work in a master/slave setup? I've locked a file on my slave > but the build doesn't tell me that the file is locked, instead it just says: > 08:59:33 Building remotely on Build1 > 08:59:33 hudson.util.IOException2: remote file operation failed: > c:\JCI\workspace\Expat\COMPILER at hudson.remoting.Channel@64368400:Build1 > 08:59:33 at hudson.FilePath.act(FilePath.java:781) > 08:59:33 at hudson.FilePath.act(FilePath.java:767) > If the plugin doesn't tell me about locked files on slaves can that > functionality be added? > Cheers, > Tom. -- 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-12577) Email notification hangs due to NullPointerException
[ https://issues.jenkins-ci.org/browse/JENKINS-12577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158650#comment-158650 ] Costin Caraivan commented on JENKINS-12577: --- More details: Jenkins 1.437 Email-ext plugin: 2.16 (by the way, versions 2.17 and 2.18 don't have changelogs listed here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin) Perforce plugin: 1.3.4 I will also attach the sanitized Jelly template. > Email notification hangs due to NullPointerException > > > Key: JENKINS-12577 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12577 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Windows 2008 Server x64, Java 1.6.0_25 >Reporter: Costin Caraivan >Priority: Blocker > > We have an email notification which uses a Jelly template. So far it worked > ok, but recently we started getting these: > Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher > sendMail > WARNING: Could not send email. > java.lang.NullPointerException > at hudson.model.Slave.createLauncher(Slave.java:311) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) -- 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-12637) URLTrigger does not poll
[
https://issues.jenkins-ci.org/browse/JENKINS-12637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158651#comment-158651
]
kirill_evstigneev commented on JENKINS-12637:
-
In 0.11 polling works well. Thanks.
> URLTrigger does not poll
>
>
> Key: JENKINS-12637
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12637
> Project: Jenkins
> Issue Type: Bug
> Components: urltrigger
>Affects Versions: current
> Environment: OS - Debian 6
> Jenkins 1.450
> URLTrigger Plugin 0.10
>Reporter: kirill_evstigneev
>Assignee: gbois
> Attachments: config.xml
>
>
> Prepare:
> # Install Jenkins;
> # Install URLTrigger plugin
> Steps to reproduce:
> # Create file {{$JENKINS_HOME/userContent/test.xml}}; add arbitrary text.
> # create "urltrigger" job ({{config.xml}} is attached):
> #- check {{http://localhost:8080/userContent/test.xml}}
> #- Inspect URL content / Monitor a change of the content
> #- poll every minute
> Result:
> - Change in {{$JENKINS_HOME/userContent/test.xml}} does not trigger new build.
> - {{http://localhost:8080/job/urltrigger/urltriggerPollLog/}} contains
> {noformat}
> [URLTrigger] - Poll with a URL
> Inspecting Monitor a change of the content content for URL
> http://localhost:8080/userContent/test.xml
> Polling has not run yet.
> {noformat}
--
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-12577) Email notification hangs due to NullPointerException
[ https://issues.jenkins-ci.org/browse/JENKINS-12577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Costin Caraivan updated JENKINS-12577: -- Attachment: template.jelly Template used. > Email notification hangs due to NullPointerException > > > Key: JENKINS-12577 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12577 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Windows 2008 Server x64, Java 1.6.0_25 >Reporter: Costin Caraivan >Priority: Blocker > Attachments: template.jelly > > > We have an email notification which uses a Jelly template. So far it worked > ok, but recently we started getting these: > Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher > sendMail > WARNING: Could not send email. > java.lang.NullPointerException > at hudson.model.Slave.createLauncher(Slave.java:311) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) -- 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-12577) Email notification hangs due to NullPointerException
[ https://issues.jenkins-ci.org/browse/JENKINS-12577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158650#comment-158650 ] Costin Caraivan edited comment on JENKINS-12577 at 2/6/12 9:26 AM: --- More details: Jenkins 1.437 Email-ext plugin: 2.16 (by the way, versions 2.17 and 2.18 don't have changelogs listed here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin) Perforce plugin: 1.3.4 I will also attach the sanitized Jelly template. Oh - the setup is distributed. The build is executed on a Windows 2008 slave connected through WMI. was (Author: ccaraivan): More details: Jenkins 1.437 Email-ext plugin: 2.16 (by the way, versions 2.17 and 2.18 don't have changelogs listed here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin) Perforce plugin: 1.3.4 I will also attach the sanitized Jelly template. > Email notification hangs due to NullPointerException > > > Key: JENKINS-12577 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12577 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Windows 2008 Server x64, Java 1.6.0_25 >Reporter: Costin Caraivan >Priority: Blocker > Attachments: template.jelly > > > We have an email notification which uses a Jelly template. So far it worked > ok, but recently we started getting these: > Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher > sendMail > WARNING: Could not send email. > java.lang.NullPointerException > at hudson.model.Slave.createLauncher(Slave.java:311) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) -- 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-10390) Axis error on JIRA plugin configuration
[ https://issues.jenkins-ci.org/browse/JENKINS-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Benítez resolved JENKINS-10390. --- Resolution: Fixed Solved following the steps in last comment on Jenkins-Jira plugin page (https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin) about downloading Axis jars. > Axis error on JIRA plugin configuration > --- > > Key: JENKINS-10390 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10390 > Project: Jenkins > Issue Type: Bug > Components: jira >Reporter: Gonzalo Benítez > > I'm trying to configure a Jira-Jenkins integration. > I'm using Jira v.4.3.3 (Accept Remote APIs is ON) and Jenkins 1.421. > When typing user & pwd for jira integration, I'm getting the following error: > javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not > initialize class org.apache.axis.client.AxisClient > org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:603) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) > org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234) > ... > ... > I don't know if I'm missing something. Any Help? -- 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-12649) Need to activate Security to see options "TCP port for JNLP slave agents" and "Markup Formatter"
Arnaud Héritier created JENKINS-12649: - Summary: Need to activate Security to see options "TCP port for JNLP slave agents" and "Markup Formatter" Key: JENKINS-12649 URL: https://issues.jenkins-ci.org/browse/JENKINS-12649 Project: Jenkins Issue Type: Bug Components: core Environment: 1.450 Reporter: Arnaud Héritier Priority: Trivial Attachments: BugConfiguration.png You need to activate security to configure these options -- 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-11723) appaloosa-plugin allow to deploy only latest binaries from the workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-11723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158654#comment-158654 ] Arnaud Héritier commented on JENKINS-11723: --- Seeing the code it seems that this order is wanted but I don't understand it. I may want to change these settings without activating the security (even if instances without security are probably limited in number) > appaloosa-plugin allow to deploy only latest binaries from the workspace > > > Key: JENKINS-11723 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11723 > Project: Jenkins > Issue Type: Improvement > Components: appaloosa > Environment: Affect 1.0 >Reporter: Arnaud Héritier >Assignee: Arnaud Héritier > > The plugin scans the workspace of the build to find binairies and deploy them. > Thus it is impossible to postpone the deployment to a manual step for example > using the promotion plugin for example. -- 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-8599) Hudson's changelog RSS feeds are 404
[ https://issues.jenkins-ci.org/browse/JENKINS-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-8599. -- Resolution: Fixed This seems to be fixed now to me. > Hudson's changelog RSS feeds are 404 > > > Key: JENKINS-8599 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8599 > Project: Jenkins > Issue Type: Bug > Components: www >Reporter: seanf > > http://hudson-labs.org/changelog has an RSS button which links to > https://hudson.dev.java.net/servlets/ProjectNewsRSS, which is 404 (since 22 > Nov 2010, according to Google Reader). > http://jenkins-ci.org/ has a different "Releases" RSS link > https://hudson.dev.java.net/servlets/ProjectRSS?type=news but it's also 404 > since 22 Nov. -- 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-11938) Jenkins loses builds when restarted
[
https://issues.jenkins-ci.org/browse/JENKINS-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158656#comment-158656
]
kirill_evstigneev commented on JENKINS-11938:
-
The same issue - when Hudson SetEnv and EnvInject 1.7 plugins are installed.
Disabling SetEnv and EnvInject upgrade to 1.17 fixes it. Not sure what is
required to fix exactly.
Underlying cause - {{build.xml}} is not written to the build folder
({{jobs/JobName/builds/(timestamp)/}}). So the build persist till Jenkins
restart only.
2 everyone - please check if the above conditions (Hudson SetEnv and EnvInject
plugins are installed) are true for your configurations.
> Jenkins loses builds when restarted
> ---
>
> Key: JENKINS-11938
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11938
> Project: Jenkins
> Issue Type: Bug
> Components: other, versionnumber
>Affects Versions: current
> Environment: tomcat 7.0.22
> windows server 2008 r2
>Reporter: Ben Dean
>
> Jenkins version 1.437
> If I stop the Apache Tomcat windows service, a bunch of my builds disappear
> from the history of the jobs. The missing builds are still on disk in the
> build folder, it just doesn't "find" them when making the history list.
> The jobs that lose history use the version number plugin and I had recently
> changed the version format from "4.3.${BUILDS_ALL_TIME}" to
> "4.4.${BUILDS_ALL_TIME}". The builds that disappear are all those after I
> changed this format. Also affects jobs that are downstream from those with
> version number changes.
> I could not find any Component related to the build history for a job. If
> someone knows what that should be feel free to change this. Also, sorry if
> there's not enough (or to much) information, this is the first Jenkins bug I
> have filed.
--
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-11898) Create view if view doesn't exist doesn't work for dynamic views
[
https://issues.jenkins-ci.org/browse/JENKINS-11898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158657#comment-158657
]
Krzysztof Malinowski commented on JENKINS-11898:
Another symptom is for base ClearCase:
$ cleartool mkview -tag
cleartool: Error: View directory pathname must be specified.
Usage: mkview -tag dynamic-view-tag [-tcomment tag-comment] [-tmode text-mode]
[-region network-region | -stream stream-selector]
[-shareable_dos | -nshareable_dos] [-cachesize size]
[-ln link-storage-to-dir-pname] [-ncaexported]
{ -stgloc {view-stgloc-name | -auto}
| [-host hostname -hpath host-stg-pname -gpath global-stg-pname]
dynamic-view-storage-pname
}
mkview -snapshot [-tag snapshot-view-tag]
[-tcomment tag-comment] [-tmode text-mode]
[-cachesize size] [-ptime] [-stream stream-selector]
[ -stgloc view-stgloc-name
| -colocated_server [-host hostname -hpath
host-snapshot-view-pname -gpath global-snapshot-view-pname]
| -vws view-storage-pname [-host hostname -hpath host-stg-pname
-gpath global-stg-pname]
] snapshot-view-pname
FATAL: Base ClearCase failed. exit code=1
Here location for dynamic view is not given at all.
> Create view if view doesn't exist doesn't work for dynamic views
>
>
> Key: JENKINS-11898
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11898
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase
>Affects Versions: current
> Environment: unix
>Reporter: Eric Le Lay
>Assignee: Vincent Latombe
> Attachments: fix+ClearCase+dynamic+view+creation.patch
>
>
> (tested with 1.3.7)
> When I check "use dynamic views" and "Create view if view doesn't exist", the
> command line generated is such :
> cleartool mkview -snapshot -stream NAME_OF_THE_STREAM_OK -tag VIEWTAG_OK
> -stgloc -auto
> Here you see a nasty "-snapshot" argument making troubles.
> The error message is "cleartool: Error: View directory pathname must be
> specified."
--
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-11898) Create view if view doesn't exist doesn't work for dynamic views
[
https://issues.jenkins-ci.org/browse/JENKINS-11898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158657#comment-158657
]
Krzysztof Malinowski edited comment on JENKINS-11898 at 2/6/12 12:06 PM:
-
Another symptom is for base ClearCase:
{noformat}
$ cleartool mkview -tag
cleartool: Error: View directory pathname must be specified.
Usage: mkview -tag dynamic-view-tag [-tcomment tag-comment] [-tmode text-mode]
[-region network-region | -stream stream-selector]
[-shareable_dos | -nshareable_dos] [-cachesize size]
[-ln link-storage-to-dir-pname] [-ncaexported]
{ -stgloc {view-stgloc-name | -auto}
| [-host hostname -hpath host-stg-pname -gpath global-stg-pname]
dynamic-view-storage-pname
}
mkview -snapshot [-tag snapshot-view-tag]
[-tcomment tag-comment] [-tmode text-mode]
[-cachesize size] [-ptime] [-stream stream-selector]
[ -stgloc view-stgloc-name
| -colocated_server [-host hostname -hpath
host-snapshot-view-pname -gpath global-snapshot-view-pname]
| -vws view-storage-pname [-host hostname -hpath host-stg-pname
-gpath global-stg-pname]
] snapshot-view-pname
FATAL: Base ClearCase failed. exit code=1
{noformat}
Here location for dynamic view is not given at all.
was (Author: raspy):
Another symptom is for base ClearCase:
$ cleartool mkview -tag
cleartool: Error: View directory pathname must be specified.
Usage: mkview -tag dynamic-view-tag [-tcomment tag-comment] [-tmode text-mode]
[-region network-region | -stream stream-selector]
[-shareable_dos | -nshareable_dos] [-cachesize size]
[-ln link-storage-to-dir-pname] [-ncaexported]
{ -stgloc {view-stgloc-name | -auto}
| [-host hostname -hpath host-stg-pname -gpath global-stg-pname]
dynamic-view-storage-pname
}
mkview -snapshot [-tag snapshot-view-tag]
[-tcomment tag-comment] [-tmode text-mode]
[-cachesize size] [-ptime] [-stream stream-selector]
[ -stgloc view-stgloc-name
| -colocated_server [-host hostname -hpath
host-snapshot-view-pname -gpath global-snapshot-view-pname]
| -vws view-storage-pname [-host hostname -hpath host-stg-pname
-gpath global-stg-pname]
] snapshot-view-pname
FATAL: Base ClearCase failed. exit code=1
Here location for dynamic view is not given at all.
> Create view if view doesn't exist doesn't work for dynamic views
>
>
> Key: JENKINS-11898
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11898
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase
>Affects Versions: current
> Environment: unix
>Reporter: Eric Le Lay
>Assignee: Vincent Latombe
> Attachments: fix+ClearCase+dynamic+view+creation.patch
>
>
> (tested with 1.3.7)
> When I check "use dynamic views" and "Create view if view doesn't exist", the
> command line generated is such :
> cleartool mkview -snapshot -stream NAME_OF_THE_STREAM_OK -tag VIEWTAG_OK
> -stgloc -auto
> Here you see a nasty "-snapshot" argument making troubles.
> The error message is "cleartool: Error: View directory pathname must be
> specified."
--
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-12650) jenkins running in Tomcat doesn't initalize slf4j properly
Alex Lehmann created JENKINS-12650: -- Summary: jenkins running in Tomcat doesn't initalize slf4j properly Key: JENKINS-12650 URL: https://issues.jenkins-ci.org/browse/JENKINS-12650 Project: Jenkins Issue Type: Bug Components: ssh Environment: jenkins 1.450, tomcat 7.0.23, java 1.6.0-30 Reporter: Alex Lehmann Priority: Minor when running tomcat, the slf4j library isn't correctly initialized, this is not a problem by itself since it simply turns off logging completely for the components that use slf, however if the logging output is needed for a component it would be better to provide the simple logger. SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. when I put the necessary jar into the war, the log output becomes this: 16 [NullIdDescriptorMonitor.verifyId] INFO org.apache.sshd.common.util.SecurityUtils - Trying to register BouncyCastle as a JCE provider 511 [NullIdDescriptorMonitor.verifyId] INFO org.apache.sshd.common.util.SecurityUtils - Registration succeeded so this is used by the sshd module in the default installation. Alternatively, the binding for jdk14 logging or log4j could be used (which ever is more fitting for the rest of jenkins). -- 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-12651) Possibility to select whether to save build or not on m2release
Roland Asmann created JENKINS-12651: --- Summary: Possibility to select whether to save build or not on m2release Key: JENKINS-12651 URL: https://issues.jenkins-ci.org/browse/JENKINS-12651 Project: Jenkins Issue Type: Improvement Components: m2release Affects Versions: current Reporter: Roland Asmann Assignee: teilo Priority: Minor We would like to be able to set whether or not we want to save the release builds in Jenkins. Optimally we would like to have this configurable in the main Jenkins configuration with the possibility to override in the jobs themselves. -- 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-1790) Fail to expand a plugin if the directory name contains space?
[ https://issues.jenkins-ci.org/browse/JENKINS-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-1790. -- Resolution: Cannot Reproduce Currently using Jenkins 1.446, I can confirm that I can install plugins when the directory contains ' ' (in particular, my windows home directory is "c:\Documents and setting\xyz"), and that for a lot of Jenkins versions > Fail to expand a plugin if the directory name contains space? > - > > Key: JENKINS-1790 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1790 > Project: Jenkins > Issue Type: Bug > Components: plugin >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: Kohsuke Kawaguchi > > Unconfirmed report on a blog indicating the plugin installation would fail if > the directory name contains ' '. > If true, this is a big problem because WIndows home directory by default > exists > under "Documents and Settings" -- 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-1334) maven integration doesn't support basic auth
[ https://issues.jenkins-ci.org/browse/JENKINS-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-1334. -- Resolution: Not A Defect I think that it was a problem with your setup of Maven in Hudson and not a problem with Hudson. But you can reopen the issue if it is still a problem, with more recent versions of Maven and Jenkins. > maven integration doesn't support basic auth > > > Key: JENKINS-1334 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1334 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: Platform: Macintosh, OS: All >Reporter: rbohn >Priority: Trivial > > I'm trying to do https with basic auth. It works great on the command-line > using the same settings.xml where the username and password for the server is > set, but fails in Hudson with a 401 authentication failed. I'm using maven > 2.0.8 on the command line and I noticed that the jars in hudson use maven > 2.0.4. -- 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-6206) ActiveDirectory groups seem to work as global admins, but not as matrix-style job members
[ https://issues.jenkins-ci.org/browse/JENKINS-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Walter Kacynski closed JENKINS-6206. > ActiveDirectory groups seem to work as global admins, but not as matrix-style > job members > - > > Key: JENKINS-6206 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6206 > Project: Jenkins > Issue Type: Bug > Components: active-directory > Environment: Windows 2003 Server, Hudson 1.342, AD plugin 1.16 >Reporter: Cervator >Priority: Minor > > We have our Hudson configured with the AD plugin to authenticate against two > different domains, and everything works great! No special config needed past > installing the plugin and entering the two domains under the global config. > However, while I can use a plain standard AD group to assign its members > admin rights in Hudson via Manage Hudson - Configure System - Project-based > Matrix Authorization Strategy, the same exact group won't give rights if > assigned directly in a job using Enable project-based security. > I can assign rights to the individual members of the group and it works fine, > so there's a pretty easy workaround. Still, I wouldn't mind if the group > option worked in both places, and hope it is something simple to fix :) > If I can provide any additional troubleshooting information, please let me > know how! I'm not very familiar with AD, so I was very happy (and a little > surprised) when it worked this well right out of the box. -- 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-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kutzi updated JENKINS-12113: Component/s: maven2 > Maven - java.io.IOException: error=2, No such file or directory if in SVN > configuration parameters used in Local module directory section > - > > Key: JENKINS-12113 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 > Project: Jenkins > Issue Type: Bug > Components: core, maven, maven2, parameters, subversion > Environment: Jenkins 1.448 > Subversion Plugin 1.37 > Maven Integration Plugin 1.448 > Ant 1.1 >Reporter: Oleksandr Popov >Assignee: kutzi >Priority: Blocker > Attachments: svn_maven_issue_01.PNG, svn_maven_issue_02.PNG > > > Maven is unable to work if in Subversion configuration parameters are used in > Local module directory section. > As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in > Local module directory section. And when I run it - Maven failed > (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[ https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158660#comment-158660 ] evernat commented on JENKINS-1955: -- Just reproduced using Jenkins 1.446, in the configure page for Ant when coming from a view. > Wrong URL to info about environment variables in help for Ant build of > grouped Job config > - > > Key: JENKINS-1955 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1955 > Project: Jenkins > Issue Type: Bug > Components: other >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: tjuerge >Priority: Minor > > If a job belongs to a group and the corresponding job configuration is > accessed > from within this group (URL = "/view//job//configure") > then the url of the hyperlink named "environment variables" in help for the > ant > build is wrong. The url points to "/view//env-vars.html" instead > of > "/env-vars.html". -- 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-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[ https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat updated JENKINS-1955: - Component/s: ant (was: other) > Wrong URL to info about environment variables in help for Ant build of > grouped Job config > - > > Key: JENKINS-1955 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1955 > Project: Jenkins > Issue Type: Bug > Components: ant >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: tjuerge >Priority: Minor > > If a job belongs to a group and the corresponding job configuration is > accessed > from within this group (URL = "/view//job//configure") > then the url of the hyperlink named "environment variables" in help for the > ant > build is wrong. The url points to "/view//env-vars.html" instead > of > "/env-vars.html". -- 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-12652) Errors on wiki.jenkins-ci.org plugins list page
Simon C. created JENKINS-12652: -- Summary: Errors on wiki.jenkins-ci.org plugins list page Key: JENKINS-12652 URL: https://issues.jenkins-ci.org/browse/JENKINS-12652 Project: Jenkins Issue Type: Bug Components: www Reporter: Simon C. Attachments: wiki-jenkins-ci-plugin-bug.png Browse to the URL https://wiki.jenkins-ci.org/display/JENKINS/Plugins This URL should show a categorised list of Jenkins plugins. It is currently showing Java error messages against a number of the plugin headings. See screenshot attached. (note: I appreciate this is the bug tracker for Jenkins itself and may not be the correct location to report errors on the Jenkins site, but I was unable to find anywhere else to report it; please feel free to move it to the correct location if necessary) -- 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-2734) JUnit reports - setting threshold of failed tests to mark build as stable/unstable/failed
[ https://issues.jenkins-ci.org/browse/JENKINS-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158661#comment-158661 ] gbois commented on JENKINS-2734: For information, xUnit plugin supports also classic JUnit results. Therefore, you can use xUnit plugin with its threshold feature to record JUnit results. > JUnit reports - setting threshold of failed tests to mark build as > stable/unstable/failed > - > > Key: JENKINS-2734 > URL: https://issues.jenkins-ci.org/browse/JENKINS-2734 > Project: Jenkins > Issue Type: Improvement > Components: junit >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: ondraz > > I would like to set maximum number of junit tests which can fail > during build and the build is marked still as stable, as unstable or as > failed. > I found this option in task plugin, compiler warnings plugin etc. but > not in jUnit reports. > see configuration section of Task Scanner plugin > http://hudson.gotdns.com/wiki/display/JENKINS/Task+Scanner+Plugin > and/or Warnings plugin > http://hudson.gotdns.com/wiki/display/JENKINS/Warnings+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-2734) JUnit reports - setting threshold of failed tests to mark build as stable/unstable/failed
[ https://issues.jenkins-ci.org/browse/JENKINS-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158662#comment-158662 ] gbois commented on JENKINS-2734: Other suggestion: I suggest also replacing the JUnit archiver by the xUnit plugin (as a native plugin) > JUnit reports - setting threshold of failed tests to mark build as > stable/unstable/failed > - > > Key: JENKINS-2734 > URL: https://issues.jenkins-ci.org/browse/JENKINS-2734 > Project: Jenkins > Issue Type: Improvement > Components: junit >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: ondraz > > I would like to set maximum number of junit tests which can fail > during build and the build is marked still as stable, as unstable or as > failed. > I found this option in task plugin, compiler warnings plugin etc. but > not in jUnit reports. > see configuration section of Task Scanner plugin > http://hudson.gotdns.com/wiki/display/JENKINS/Task+Scanner+Plugin > and/or Warnings plugin > http://hudson.gotdns.com/wiki/display/JENKINS/Warnings+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-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kutzi updated JENKINS-12113: Priority: Major (was: Blocker) This is arguably no 'Blocker' issue. Blocker is if you can't use something at all - for this issue there are some obvious workarounds. > Maven - java.io.IOException: error=2, No such file or directory if in SVN > configuration parameters used in Local module directory section > - > > Key: JENKINS-12113 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 > Project: Jenkins > Issue Type: Bug > Components: core, maven, maven2, parameters, subversion > Environment: Jenkins 1.448 > Subversion Plugin 1.37 > Maven Integration Plugin 1.448 > Ant 1.1 >Reporter: Oleksandr Popov >Assignee: kutzi > Attachments: svn_maven_issue_01.PNG, svn_maven_issue_02.PNG > > > Maven is unable to work if in Subversion configuration parameters are used in > Local module directory section. > As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in > Local module directory section. And when I run it - Maven failed > (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[
https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158664#comment-158664
]
evernat commented on JENKINS-1955:
--
And it's the same in the help for Maven ("Invoke top-level Maven targets") of a
free style project.
> Wrong URL to info about environment variables in help for Ant build of
> grouped Job config
> -
>
> Key: JENKINS-1955
> URL: https://issues.jenkins-ci.org/browse/JENKINS-1955
> Project: Jenkins
> Issue Type: Bug
> Components: ant
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: tjuerge
>Priority: Minor
>
> If a job belongs to a group and the corresponding job configuration is
> accessed
> from within this group (URL = "/view//job//configure")
> then the url of the hyperlink named "environment variables" in help for the
> ant
> build is wrong. The url points to "/view//env-vars.html" instead
> of
> "/env-vars.html".
--
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-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kutzi updated JENKINS-12113: Attachment: subversion.hpi Looks like this can be fixed quite easily by overriding the newer getModuleRoot(s) methods . Could you please try the attached updated subversion plugin if it fixes your issue? > Maven - java.io.IOException: error=2, No such file or directory if in SVN > configuration parameters used in Local module directory section > - > > Key: JENKINS-12113 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 > Project: Jenkins > Issue Type: Bug > Components: core, maven, maven2, parameters, subversion > Environment: Jenkins 1.448 > Subversion Plugin 1.37 > Maven Integration Plugin 1.448 > Ant 1.1 >Reporter: Oleksandr Popov >Assignee: kutzi > Attachments: subversion.hpi, svn_maven_issue_01.PNG, > svn_maven_issue_02.PNG > > > Maven is unable to work if in Subversion configuration parameters are used in > Local module directory section. > As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in > Local module directory section. And when I run it - Maven failed > (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[
https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158664#comment-158664
]
evernat edited comment on JENKINS-1955 at 2/6/12 2:54 PM:
--
And it's the same in the help for Maven ("Invoke top-level Maven targets") of a
free style project.
https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/help/project-config/maven.html
was (Author: evernat):
And it's the same in the help for Maven ("Invoke top-level Maven targets")
of a free style project.
> Wrong URL to info about environment variables in help for Ant build of
> grouped Job config
> -
>
> Key: JENKINS-1955
> URL: https://issues.jenkins-ci.org/browse/JENKINS-1955
> Project: Jenkins
> Issue Type: Bug
> Components: ant
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: tjuerge
>Priority: Minor
>
> If a job belongs to a group and the corresponding job configuration is
> accessed
> from within this group (URL = "/view//job//configure")
> then the url of the hyperlink named "environment variables" in help for the
> ant
> build is wrong. The url points to "/view//env-vars.html" instead
> of
> "/env-vars.html".
--
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-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[ https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158660#comment-158660 ] evernat edited comment on JENKINS-1955 at 2/6/12 2:54 PM: -- Just reproduced using Jenkins 1.446, in the configure page for Ant when coming from a view. https://github.com/jenkinsci/ant-plugin/blob/master/src/main/resources/hudson/tasks/Ant/help.html was (Author: evernat): Just reproduced using Jenkins 1.446, in the configure page for Ant when coming from a view. > Wrong URL to info about environment variables in help for Ant build of > grouped Job config > - > > Key: JENKINS-1955 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1955 > Project: Jenkins > Issue Type: Bug > Components: ant >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: tjuerge >Priority: Minor > > If a job belongs to a group and the corresponding job configuration is > accessed > from within this group (URL = "/view//job//configure") > then the url of the hyperlink named "environment variables" in help for the > ant > build is wrong. The url points to "/view//env-vars.html" instead > of > "/env-vars.html". -- 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-12653) Need Plugin for passing credentials to Post Script in XCode Builds
Shri iDev created JENKINS-12653: --- Summary: Need Plugin for passing credentials to Post Script in XCode Builds Key: JENKINS-12653 URL: https://issues.jenkins-ci.org/browse/JENKINS-12653 Project: Jenkins Issue Type: Improvement Components: xcode Environment: xcode, iOS Reporter: Shri iDev Priority: Blocker I am trying to implement complete end to end automation from generating the build and running automation test on that build. I have been able to generate the build and now trying to run the automation by running the a post script. To invoke the instruments tools I need to use "Sudo" command which needs to be run on the super user or needs login id and password to be passed of the current user. Without sudo command following error comes up: "instruments[64703:60f] -[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better. _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. Mon Feb 6 13:15:20 inpunml310743 instruments[64703] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. 2012-02-06 13:15:20.179 instruments[64703:60f] Recording cancelled : At least one target failed to launch; aborting run Instruments Trace Error : Failed to start trace. Build step 'Execute shell' marked build as failure Finished: FAILURE" with sudo command(since it does not get password) this error comes: sudo: no tty present and no askpass program specified. PS: I am able to run the script manually by double clicking and it starts the instruments tools for automation. This does not work with jenkins only as it I think tries to remotely access the application(I am running jenkins on localhost). Please help as it of very high priority for me. -- 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-12653) Need Plugin for passing credentials to Post Script in XCode Builds
[ https://issues.jenkins-ci.org/browse/JENKINS-12653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shri iDev updated JENKINS-12653: Description: I am trying to implement complete end to end automation from generating the build and running automation test on that build for iPhone using Xcode plugin. I have been able to generate the build and now trying to run the automation by running the a post script. To invoke the instruments tools I need to use "Sudo" command which needs to be run on the super user or needs login id and password to be passed of the current user. Without sudo command following error comes up: "instruments[64703:60f] -[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better. _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. Mon Feb 6 13:15:20 inpunml310743 instruments[64703] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. 2012-02-06 13:15:20.179 instruments[64703:60f] Recording cancelled : At least one target failed to launch; aborting run Instruments Trace Error : Failed to start trace. Build step 'Execute shell' marked build as failure Finished: FAILURE" with sudo command(since it does not get password) this error comes: sudo: no tty present and no askpass program specified. PS: I am able to run the script manually by double clicking and it starts the instruments tools for automation. This does not work with jenkins only as it I think tries to remotely access the application(I am running jenkins on localhost). Please help as it of very high priority for me. was: I am trying to implement complete end to end automation from generating the build and running automation test on that build. I have been able to generate the build and now trying to run the automation by running the a post script. To invoke the instruments tools I need to use "Sudo" command which needs to be run on the super user or needs login id and password to be passed of the current user. Without sudo command following error comes up: "instruments[64703:60f] -[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better. _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. Mon Feb 6 13:15:20 inpunml310743 instruments[64703] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. 2012-02-06 13:15:20.179 instruments[64703:60f] Recording cancelled : At least one target failed to launch; aborting run Instruments Trace Error : Failed to start trace. Build step 'Execute shell' marked build as failure Finished: FAILURE" with sudo command(since it does not get password) this error comes: sudo: no tty present and no askpass program specified. PS: I am able to run the script manually by double clicking and it starts the instruments tools for automation. This does not work with jenkins only as it I think tries to remotely access the application(I am running jenkins on localhost). Please help as it of very high priority for me. Due Date: 7/Feb/12 > Need Plugin for passing credentials to Post Script in XCode Builds > -- > > Key: JENKINS-12653 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12653 > Project: Jenkins > Issue Type: Improvement > Components: xcode > Environment: xcode, iOS >Reporter: Shri iDev >Priority: Blocker > > I am trying to implement complete end to end automation from generating the > build and running automation test on that build for iPhone using Xcode > plugin. I have been able to generate the build and now trying to run the > automation by running the a post script. To invoke the instruments tools I > need to use "Sudo" command which needs to be run on the super user or needs > login id and password to be passed of the current user. Without sudo command > following error comes up: > "instruments[64703:60f] -[NSAlert alertWithError:] called with nil NSError. A > generic error message will be displayed, but the user deserves better. > _RegisterApplication(), FAILED TO establish the default connection to the > WindowServer, _CGSDefaultConnection() is NULL. Mon Feb 6 13:15:20 > inpunml310743 instruments[64703] : kCGErrorFailure: Set a breakpoint @ > CGErrorBreakpoint() to catch errors as they are logged. 2012-02-06 > 13:15:20.179 instruments[64703:60f] Recording cancelled : At least one target > failed to launch; aborting run Instruments Trace Error : Failed to start > trace. Build step 'Execute shell' marked build as failure Finished: FAILURE" > with sudo command(since
[JIRA] (JENKINS-1955) Wrong URL to info about environment variables in help for Ant build of grouped Job config
[
https://issues.jenkins-ci.org/browse/JENKINS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158666#comment-158666
]
evernat commented on JENKINS-1955:
--
Does it need a jelly file with {rootUrl} and a properties file like the
following ?
https://github.com/jenkinsci/subversion-plugin/blob/svn/src/main/resources/hudson/scm/SubversionSCM/DescriptorImpl/url-help.jelly
https://github.com/jenkinsci/subversion-plugin/blob/svn/src/main/resources/hudson/scm/SubversionSCM/DescriptorImpl/url-help.properties
> Wrong URL to info about environment variables in help for Ant build of
> grouped Job config
> -
>
> Key: JENKINS-1955
> URL: https://issues.jenkins-ci.org/browse/JENKINS-1955
> Project: Jenkins
> Issue Type: Bug
> Components: ant
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: tjuerge
>Priority: Minor
>
> If a job belongs to a group and the corresponding job configuration is
> accessed
> from within this group (URL = "/view//job//configure")
> then the url of the hyperlink named "environment variables" in help for the
> ant
> build is wrong. The url points to "/view//env-vars.html" instead
> of
> "/env-vars.html".
--
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-1956) Tagging build to an existing tag causes SVN error
[ https://issues.jenkins-ci.org/browse/JENKINS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-1956. -- Resolution: Not A Defect I personnaly think that the default behavior should not be to overwrite an existing svn tag and that it is right to give an error. Because overwriting a svn tag does not seem a good practice. Given the low vote count after more than 3 years, this issue is closed as not a defect. You can reopen it if you feel different. Anyway the svn-tag plugin seems to be an alternative for your use case. > Tagging build to an existing tag causes SVN error > - > > Key: JENKINS-1956 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1956 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: smason > > When trying to tag a build to an existing tag I get this error: > Tagging http://PROJECT/trunk (rev.7) to http://PROJECT/tags/uat > Failed to tag > org.tmatesoft.svn.core.SVNException: svn: Path 'tags/uat' already exists > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40) > at > org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:312) > at > hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:167) > at hudson.model.TaskThread.run(TaskThread.java:77) > Completed > I would expect behaviour similar to the svn-tag plugin instead, where if the > tag > already exists it is over-written (perhaps with a warning/confirmation first). -- 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-12648) TestNG 0.31 does not show test results when tests failed
[ https://issues.jenkins-ci.org/browse/JENKINS-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158668#comment-158668 ] nalin_makar commented on JENKINS-12648: --- Could you please update the bug with the build logs? Also, check to see the webserver/console logs where jenkins is running. > TestNG 0.31 does not show test results when tests failed > > > Key: JENKINS-12648 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12648 > Project: Jenkins > Issue Type: Bug > Components: testng >Affects Versions: current >Reporter: Peter Lustig >Assignee: nalin_makar >Priority: Critical > Labels: testng > > Whenever I use the TestNG-Plugin 0.31 it only shows reports if the tests > passed. But if the failey there are no test results. If I downgrade to 0.26 > for example everthing works fine. Both the failed and passed test results are > displayed. Please fix this, would be very important. Thank you! -- 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-2158) If Maven runs the test suite multiple times the Test Result Trend graph and Stats are increased with each run.
[ https://issues.jenkins-ci.org/browse/JENKINS-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-2158. -- Resolution: Duplicate This issue is certainly a duplicate of JENKINS-1557 and it was certainly fixed with JENKINS-1557. Please reopen this issue if it was not the case. > If Maven runs the test suite multiple times the Test Result Trend graph and > Stats are increased with each run. > -- > > Key: JENKINS-2158 > URL: https://issues.jenkins-ci.org/browse/JENKINS-2158 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: Platform: All, OS: Linux >Reporter: abonderud > > My team uses the Clover2 plugin for Maven. Due to the structure of Clover, > the > testing suite is run twice. The test result graph and failure listing > displayed > in Hudson have values that are double what they should be. This is an > inaccurate representation of the data. The Surefire plugin reports it > correctly > however. -- 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-2807) Hudson FATAL error when switching JDK (m2 support)
[
https://issues.jenkins-ci.org/browse/JENKINS-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
evernat resolved JENKINS-2807.
--
Resolution: Duplicate
Yes it seems like a duplicate of JENKINS-1454, so resolving as duplicate.
Please reopen if needed.
> Hudson FATAL error when switching JDK (m2 support)
> --
>
> Key: JENKINS-2807
> URL: https://issues.jenkins-ci.org/browse/JENKINS-2807
> Project: Jenkins
> Issue Type: Bug
> Components: maven2
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: lacostej
>
> How to reproduce:
> 1- have a build with a profile that triggers different modules based on jdk.
> 2- build
> 3- switch JDK so that another module is built
> Expected:
> * build passes
> Got:
> booom:
> java.lang.AssertionError: reporters.get($GROUPID:$ARTIFACTID)==null.
> reporters={
> LIST OF REPORTERS}
> at
> hudson.maven.MavenModuleSetBuild$Builder.postModule(MavenModuleSetBuild.java:572)
> at
> hudson.maven.MavenBuilder$Adapter.fireLeaveModule(MavenBuilder.java:284)
> at hudson.maven.MavenBuilder$Adapter.postBuild(MavenBuilder.java:242)
> at
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:45)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at hudson.maven.agent.Main.launch(Main.java:135)
> at hudson.maven.MavenBuilder.call(MavenBuilder.java:139)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:542)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:488)
> at hudson.remoting.UserRequest.perform(UserRequest.java:69)
> at hudson.remoting.UserRequest.perform(UserRequest.java:23)
> at hudson.remoting.Request$2.run(Request.java:213)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
> $GROUPID:$ARTIFACTID matches the module now newly triggered, (was never
> triggered before)
> Here's a code snippet that shows the m2 profile module selection based on JDK.
>
>
> jdk14
>
> 1.4
>
>
> X-14
>
>
>
> jdk15
>
> 1.5
>
>
> X-14
>
>
>
> jdk16
>
> 1.6
>
>
> X-16
>
>
>
--
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-12648) TestNG 0.31 does not show test results when tests failed
[ https://issues.jenkins-ci.org/browse/JENKINS-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158668#comment-158668 ] nalin_makar edited comment on JENKINS-12648 at 2/6/12 3:50 PM: --- Could you please update the bug with the build logs? Also, look for testng logs on the webserver or console where jenkins is running. was (Author: nalin_makar): Could you please update the bug with the build logs? Also, check to see the webserver/console logs where jenkins is running. > TestNG 0.31 does not show test results when tests failed > > > Key: JENKINS-12648 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12648 > Project: Jenkins > Issue Type: Bug > Components: testng >Affects Versions: current >Reporter: Peter Lustig >Assignee: nalin_makar >Priority: Critical > Labels: testng > > Whenever I use the TestNG-Plugin 0.31 it only shows reports if the tests > passed. But if the failey there are no test results. If I downgrade to 0.26 > for example everthing works fine. Both the failed and passed test results are > displayed. Please fix this, would be very important. Thank you! -- 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-12648) TestNG 0.31 does not show test results when tests failed
[ https://issues.jenkins-ci.org/browse/JENKINS-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158671#comment-158671 ] nalin_makar commented on JENKINS-12648: --- Also, I just tested this out locally but could not reproduce it. It'll help to see screenshots of the graphs or test results with v0.26 vs 0.31. Basically all the information you can provide and/or any steps to repro. Thanks! > TestNG 0.31 does not show test results when tests failed > > > Key: JENKINS-12648 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12648 > Project: Jenkins > Issue Type: Bug > Components: testng >Affects Versions: current >Reporter: Peter Lustig >Assignee: nalin_makar >Priority: Critical > Labels: testng > > Whenever I use the TestNG-Plugin 0.31 it only shows reports if the tests > passed. But if the failey there are no test results. If I downgrade to 0.26 > for example everthing works fine. Both the failed and passed test results are > displayed. Please fix this, would be very important. Thank you! -- 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-12654) View storage location is no longer saved
Krzysztof Malinowski created JENKINS-12654: -- Summary: View storage location is no longer saved Key: JENKINS-12654 URL: https://issues.jenkins-ci.org/browse/JENKINS-12654 Project: Jenkins Issue Type: Bug Components: clearcase Environment: RHEL 5.4 x64, Jenkins 1.450, Clearcase plugin 1.3.7 Reporter: Krzysztof Malinowski Assignee: Vincent Latombe Priority: Minor After upgrade to 1.3.7 changes in Unix and Windows storage directory on the project configuration page are not saved and reset to default when opening configuration page again. -- 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:all-tabpanel ] Work on JENKINS-11375 started by Krzysztof Malinowski. > 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
[JIRA] (JENKINS-10702) Need option to set the primary group of the user for all clearcase operations (newgrp)
[ https://issues.jenkins-ci.org/browse/JENKINS-10702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158672#comment-158672 ] Krzysztof Malinowski commented on JENKINS-10702: This is non-trivial, since newgrp actually executes a new shell and new group is set only within this shell. Since Jenkins is not talking to a shell but rather executes processes directly this is not possible without some major logic in command launcher. I'm not saying it's not possible, but it's definitely not a one-liner. > Need option to set the primary group of the user for all clearcase operations > (newgrp) > -- > > Key: JENKINS-10702 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10702 > Project: Jenkins > Issue Type: Improvement > Components: clearcase >Affects Versions: current > Environment: RHEL 5.0 >Reporter: Phil Rumble >Assignee: Vincent Latombe > Fix For: current > > > We have a single user that has access to all the clearcase vobs. However > access to each of the vobs is restricted by the user's primary group. We have > several groups. We currently alter this by using the newgrp command. > Can Jenkins enable this option too? > Thanks > Rumble -- 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-12655) GIT_BRANCH is incorrect in build steps when branch choosing strategy is set to inverse (but it is correct in build name macro)
Ruth Morgenstein created JENKINS-12655:
--
Summary: GIT_BRANCH is incorrect in build steps when branch
choosing strategy is set to inverse (but it is correct in build name macro)
Key: JENKINS-12655
URL: https://issues.jenkins-ci.org/browse/JENKINS-12655
Project: Jenkins
Issue Type: Bug
Components: git
Reporter: Ruth Morgenstein
Assignee: abayer
Context: I'm trying to create a parameterized job chain for our branches.
1) Set the git branch to */master and in advanced, select branching strategy =
inverse
2) Set the build name (using plugin) to #${BUILD_NUMBER}.${GIT_BRANCH}
3) In the build, use shell to execute: echo ${BUILD_BRANCH}
4) Push a change into a branch in git then manually start the build in Jenkins
Result:
The build string is set correctly to the branch used in step#4, but the echo in
step #3 incorrectly says origin/master. Note, that the wrong GIT_BRANCH is also
sent in my parameterized trigger.
The setting for GIT_BRANCH is correct at all times when Default choosing
strategy is 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-12655) GIT_BRANCH is incorrect in build steps when branch choosing strategy is set to inverse (but it is correct in build name macro)
[
https://issues.jenkins-ci.org/browse/JENKINS-12655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruth Morgenstein updated JENKINS-12655:
---
Description:
Context: I'm trying to create a parameterized job chain for our branches.
Version info:
Jenkins 1.450
Git 1.1.15
build-name-setter 1.3
parametrized trigger 2.12
1) Set the git branch to */master and in advanced, select branching strategy =
inverse
2) Set the build name (using plugin) to #${BUILD_NUMBER}.${GIT_BRANCH}
3) In the build, use shell to execute: echo ${BUILD_BRANCH}
4) Push a change into a branch in git then manually start the build in Jenkins
Result:
The build string is set correctly to the branch used in step#4, but the echo in
step #3 incorrectly says origin/master. Note, that the wrong GIT_BRANCH is also
sent in my parameterized trigger.
The setting for GIT_BRANCH is correct at all times when Default choosing
strategy is selected.
was:
Context: I'm trying to create a parameterized job chain for our branches.
1) Set the git branch to */master and in advanced, select branching strategy =
inverse
2) Set the build name (using plugin) to #${BUILD_NUMBER}.${GIT_BRANCH}
3) In the build, use shell to execute: echo ${BUILD_BRANCH}
4) Push a change into a branch in git then manually start the build in Jenkins
Result:
The build string is set correctly to the branch used in step#4, but the echo in
step #3 incorrectly says origin/master. Note, that the wrong GIT_BRANCH is also
sent in my parameterized trigger.
The setting for GIT_BRANCH is correct at all times when Default choosing
strategy is selected.
> GIT_BRANCH is incorrect in build steps when branch choosing strategy is set
> to inverse (but it is correct in build name macro)
> --
>
> Key: JENKINS-12655
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12655
> Project: Jenkins
> Issue Type: Bug
> Components: git
>Reporter: Ruth Morgenstein
>Assignee: abayer
>
> Context: I'm trying to create a parameterized job chain for our branches.
> Version info:
> Jenkins 1.450
> Git 1.1.15
> build-name-setter 1.3
> parametrized trigger 2.12
> 1) Set the git branch to */master and in advanced, select branching strategy
> = inverse
> 2) Set the build name (using plugin) to #${BUILD_NUMBER}.${GIT_BRANCH}
> 3) In the build, use shell to execute: echo ${BUILD_BRANCH}
> 4) Push a change into a branch in git then manually start the build in Jenkins
> Result:
> The build string is set correctly to the branch used in step#4, but the echo
> in step #3 incorrectly says origin/master. Note, that the wrong GIT_BRANCH is
> also sent in my parameterized trigger.
> The setting for GIT_BRANCH is correct at all times when Default choosing
> strategy is 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
Re: [JIRA] (JENKINS-12599) IllegalArgumentException after Upgrade to 2.0
The fix dint worked for me still getting the same exception: Started by user rohit Building in workspace /../Jenkins/etc/workspace/autotest FATAL: Unrecognized CVS Root: :ext:ro...@cvs-collabnet.uk.db.com:/cvsroot/xyz java.lang.IllegalArgumentException: Unrecognized CVS Root: :ext:roh...@cvs-collabnet.uk.db.com:/cvsroot/xyz at org.netbeans.lib.cvsclient.connection.ConnectionFactory.getConnection(ConnectionFactory.java:117) at hudson.scm.CVSSCM.getCvsClient(CVSSCM.java:561) at hudson.scm.CVSSCM.perform(CVSSCM.java:859) at hudson.scm.CVSSCM.checkout(CVSSCM.java:795) at hudson.model.AbstractProject.checkout(AbstractProject.java:1195) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465) at hudson.model.Run.run(Run.java:1404) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) What I did: 1) Took the latest snapshot (cvs-2.1-SNAPSHOT.hpi) for the CVS plugin from http://ci.jenkins-ci.org/job/plugins_cvs/4/org.jenkins-ci.plugins$cvs/ 2) Then replaced this with the existing cvs.hpi in jenkins.war file and rebuilt the war Correct me if I am doing something wrong? Also, If I update the cvs protocol from :ext to :pserver or etc... It will still persist the protocol :ext. Please help on this! Regards, Rohit Shingalapur -- View this message in context: http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-12599-IllegalArgumentException-after-Upgrade-to-2-0-tp4344128p4362472.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-12588) git-plugin only as optional dependency
[ https://issues.jenkins-ci.org/browse/JENKINS-12588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158448#comment-158448 ] Gerd Zanker edited comment on JENKINS-12588 at 2/6/12 8:16 PM: --- Code examples for optional dependencies http://www.google.com/url?sa=D&q=https://github.com/jenkinsci/warnings-plugin/blob/master/src/main/java/hudson/plugins/warnings/dashboard/WarningsNewVersusFixedGraphPortlet.java&usg=AFQjCNER2xnJiKUgmZKLHwqoFbyajOYk2Q was (Author: gerd_zanker): Code examples for optional dependencies https://github.com/jenkinsci/join-plugin/blob/400bf3441f47d1ea7e726605a75baf6bd7d41f9d/src/main/java/join/JoinTrigger.java https://github.com/jenkinsci/cppcheck-plugin/blob/bdc2467e769c14805414663ceeca555286f30639/src/main/java/com/thalesgroup/hudson/plugins/cppcheck/CppcheckPublisher.java > git-plugin only as optional dependency > -- > > Key: JENKINS-12588 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12588 > Project: Jenkins > Issue Type: Task > Components: trac >Reporter: Gerd Zanker >Assignee: Gerd Zanker > > With JENKINS-11887 a new mandatory dependency to the git-plugin was > introduced. This dependency shall be changed into an optional dependency. > Read more > [here|https://wiki.jenkins-ci.org/display/JENKINS/Dependencies+among+plugins] -- 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-12645) Violations plugin reports its own failures as build failures
[
https://issues.jenkins-ci.org/browse/JENKINS-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158710#comment-158710
]
acdha commented on JENKINS-12645:
-
I found a more annoying variant when something when wrong parsing our JSLint
output:
{{{
ERROR: Publisher hudson.plugins.violations.ViolationsPublisher aborted due to
exception
java.io.EOFException: input contained no data
at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at
hudson.plugins.violations.parse.AbstractParser.expectNextTag(AbstractParser.java:262)
at
hudson.plugins.violations.types.jslint.JsLintParser.execute(JsLintParser.java:25)
at
hudson.plugins.violations.parse.AbstractTypeParser.parse(AbstractTypeParser.java:57)
at
hudson.plugins.violations.ViolationsCollector.doType(ViolationsCollector.java:187)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:114)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:25)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at
hudson.plugins.violations.ViolationsPublisher.perform(ViolationsPublisher.java:74)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Build did not succeed and the project is configured to only push after a
successful build, so no pushing will occur.
}}}
> Violations plugin reports its own failures as build failures
>
>
> Key: JENKINS-12645
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12645
> Project: Jenkins
> Issue Type: Bug
> Components: violations
>Reporter: acdha
>Assignee: peterkittreilly
>
> Violations will cause a build to be marked as failed due to build
> configuration problems - for example if the coverage.py HTML path is empty or
> incorrect, the build will inaccurately be reported as failing and spam
> innocent committers. It should be marked as aborted or some other state
> indicating that the tests actually passed but there was something wrong
> within the Jenkins environment.
> {{{
> ERROR: failed to find coverage HTML reports
> Build step 'Publish coverage.py HTML reports' changed build result to FAILURE
> }}}
--
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-12645) Violations plugin reports its own failures as build failures
[
https://issues.jenkins-ci.org/browse/JENKINS-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
acdha updated JENKINS-12645:
Description:
Violations will cause a build to be marked as failed due to build configuration
problems - for example if the coverage.py HTML path is empty or incorrect, the
build will inaccurately be reported as failing and spam innocent committers. It
should be marked as aborted or some other state indicating that the tests
actually passed but there was something wrong within the Jenkins environment.
{code}
ERROR: failed to find coverage HTML reports
Build step 'Publish coverage.py HTML reports' changed build result to FAILURE
{code}
was:
Violations will cause a build to be marked as failed due to build configuration
problems - for example if the coverage.py HTML path is empty or incorrect, the
build will inaccurately be reported as failing and spam innocent committers. It
should be marked as aborted or some other state indicating that the tests
actually passed but there was something wrong within the Jenkins environment.
{{{
ERROR: failed to find coverage HTML reports
Build step 'Publish coverage.py HTML reports' changed build result to FAILURE
}}}
> Violations plugin reports its own failures as build failures
>
>
> Key: JENKINS-12645
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12645
> Project: Jenkins
> Issue Type: Bug
> Components: violations
>Reporter: acdha
>Assignee: peterkittreilly
>
> Violations will cause a build to be marked as failed due to build
> configuration problems - for example if the coverage.py HTML path is empty or
> incorrect, the build will inaccurately be reported as failing and spam
> innocent committers. It should be marked as aborted or some other state
> indicating that the tests actually passed but there was something wrong
> within the Jenkins environment.
> {code}
> ERROR: failed to find coverage HTML reports
> Build step 'Publish coverage.py HTML reports' changed build result to FAILURE
> {code}
--
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-12645) Violations plugin reports its own failures as build failures
[
https://issues.jenkins-ci.org/browse/JENKINS-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158710#comment-158710
]
acdha edited comment on JENKINS-12645 at 2/6/12 8:28 PM:
-
I found a more annoying variant when something when wrong parsing our JSLint
output:
{code}
ERROR: Publisher hudson.plugins.violations.ViolationsPublisher aborted due to
exception
java.io.EOFException: input contained no data
at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at
hudson.plugins.violations.parse.AbstractParser.expectNextTag(AbstractParser.java:262)
at
hudson.plugins.violations.types.jslint.JsLintParser.execute(JsLintParser.java:25)
at
hudson.plugins.violations.parse.AbstractTypeParser.parse(AbstractTypeParser.java:57)
at
hudson.plugins.violations.ViolationsCollector.doType(ViolationsCollector.java:187)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:114)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:25)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at
hudson.plugins.violations.ViolationsPublisher.perform(ViolationsPublisher.java:74)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Build did not succeed and the project is configured to only push after a
successful build, so no pushing will occur.
{code}
was (Author: acdha):
I found a more annoying variant when something when wrong parsing our
JSLint output:
{{{
ERROR: Publisher hudson.plugins.violations.ViolationsPublisher aborted due to
exception
java.io.EOFException: input contained no data
at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at
hudson.plugins.violations.parse.AbstractParser.expectNextTag(AbstractParser.java:262)
at
hudson.plugins.violations.types.jslint.JsLintParser.execute(JsLintParser.java:25)
at
hudson.plugins.violations.parse.AbstractTypeParser.parse(AbstractTypeParser.java:57)
at
hudson.plugins.violations.ViolationsCollector.doType(ViolationsCollector.java:187)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:114)
at
hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:25)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at
hudson.plugins.violations.ViolationsPublisher.perform(ViolationsPublisher.java:74)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Build did not succeed and the project is configured to only push after a
successful build, so no pushing will occur.
}}}
> Violations plugin reports its own failures as build failures
>
>
> Key: JENKINS-12645
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12645
>
[JIRA] (JENKINS-12588) git-plugin only as optional dependency
[ https://issues.jenkins-ci.org/browse/JENKINS-12588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158711#comment-158711 ] Gerd Zanker commented on JENKINS-12588: --- fixed issue with https://github.com/GerdZanker/trac-plugin/commit/59298b3d40343560bc30c5bf8f91ffbff5e402a8 > git-plugin only as optional dependency > -- > > Key: JENKINS-12588 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12588 > Project: Jenkins > Issue Type: Task > Components: trac >Reporter: Gerd Zanker >Assignee: Gerd Zanker > > With JENKINS-11887 a new mandatory dependency to the git-plugin was > introduced. This dependency shall be changed into an optional dependency. > Read more > [here|https://wiki.jenkins-ci.org/display/JENKINS/Dependencies+among+plugins] -- 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-12656) Have wall display link use current viewName
Kevin Priest created JENKINS-12656: -- Summary: Have wall display link use current viewName Key: JENKINS-12656 URL: https://issues.jenkins-ci.org/browse/JENKINS-12656 Project: Jenkins Issue Type: Improvement Components: walldisplay Affects Versions: current Reporter: Kevin Priest Assignee: Christian Pelster Priority: Minor Have the left side link for walldisplay use the full view name in viewName. We have non-unique view names so the highest match view is always used. ie: page displayed - http://jenkins:8080/view/Dashboard walldisplay link - http://jenkins:8080//plugin/jenkinswalldisplay/walldisplay.html?viewName=Dashboard&jenkinsUrl=http%3A%2F%2Fjenkins%3A8080%2F page displayed - http://jenkins:8080/view/Product/view/Dashboard walldisplay link - http://jenkins:8080//plugin/jenkinswalldisplay/walldisplay.html?viewName=Dashboard&jenkinsUrl=http%3A%2F%2Fjenkins%3A8080%2F should be - http://jenkins:8080//plugin/jenkinswalldisplay/walldisplay.html?viewName=Product/view/Dashboard&jenkinsUrl=http%3A%2F%2Fjenkins%3A8080%2F page displayed - http://jenkins:8080/view/Product/view/Product_A walldisplay link - http://jenkins:8080//plugin/jenkinswalldisplay/walldisplay.html?viewName=Product_A&jenkinsUrl=http%3A%2F%2Fjenkins%3A8080%2F should be - http://jenkins:8080//plugin/jenkinswalldisplay/walldisplay.html?viewName=Product/view/Product_A&jenkinsUrl=http%3A%2F%2Fjenkins%3A8080%2F all exist -- 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-12657) Matrix configuration node Label - job not running on specified node with that Label
Andre Untiedt created JENKINS-12657: --- Summary: Matrix configuration node Label - job not running on specified node with that Label Key: JENKINS-12657 URL: https://issues.jenkins-ci.org/browse/JENKINS-12657 Project: Jenkins Issue Type: Bug Components: master-slave, matrix Affects Versions: current Environment: Red Hat Enterprise Linux Server release 5.6 (Tikanga) Reporter: Andre Untiedt Fix For: current Slave labeled 'android'. Configuration Matrix, Slaves Node/Label: Labels 'android' selected. Expected: Job runs on slave labeled 'android'. Actual: Job runs on another, random slave. -- 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-12658) Coverage report: module-level deltas
acdha created JENKINS-12658: --- Summary: Coverage report: module-level deltas Key: JENKINS-12658 URL: https://issues.jenkins-ci.org/browse/JENKINS-12658 Project: Jenkins Issue Type: Improvement Components: cobertura Reporter: acdha Assignee: stephenconnolly Priority: Minor It would be extremely nice if the coverage report could list at least a package-level ± coverage percentage delta to make it easier to see when a single checkin added a large number of uncovered lines versus the same number of uncovered lines growing in small, gradually numbers across many commits. -- 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-12659) GitPublisher won't work as promote action
Alexandre Normand created JENKINS-12659: --- Summary: GitPublisher won't work as promote action Key: JENKINS-12659 URL: https://issues.jenkins-ci.org/browse/JENKINS-12659 Project: Jenkins Issue Type: Improvement Components: git Affects Versions: current Environment: Linux CentOS Reporter: Alexandre Normand Assignee: abayer Promote actions list GitPublisher as one of the available items. However, when configured as a promote action, GitPublisher always fails. I remote debugged GitPublisher to find out why and it turns out that build.getProject().getScm() is a NullSCM instead of a GitSCM instance. I'm assuming that somehow, the SCM instance doesn't apply to promote (the SCM is configured to a valid git repository in the job config and the pulls are done without problems). Since we're used to have tagging done on build promotion and it's a valid use case, I think it would be nice if either: 1. Promote actions would also get access to the GitSCM instance to be able to perform the operation. 2. The GitPublisher could be given enough information to create a GitSCM instance and tag when under promote (repository url, commit hash matching the promoted build). I've looked a bit at the GitPublisher code and I'm willing to do some work but I would like some input as to the best solution. -- 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-11913) Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix resolved JENKINS-11913. --- Resolution: Duplicate Duplicate of JENKINS-11683 > Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs > -- > > Key: JENKINS-11913 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11913 > Project: Jenkins > Issue Type: Bug > Components: email-ext > Environment: occurs in email-ext plugin version 2.16 >Reporter: rvaughn >Assignee: Slide-O-Mix >Priority: Critical > Labels: email, email-ext, plugin > > Version 2.16 of the plugin removes support for the PROJECT_DEFAULT_RECIPIENTS > token, but leaves references to the token in the recipient lists for > previously-configured build jobs. This causes build to attempt to send email > to "$PROJECT_DEFAULT_RECIPIENTS" (literally), which of course fails. Delivery > to legitimate addresses fails at the same time. > This is a breaking change, as it requires manually editing all existing jobs > to remove the offending token reference. For installations with many jobs, > this could be overwhelming. In general, it's not a good idea to remove > functionality like this, therefore forcing your users to immediately > reconfigure to use your alternate method. (i.e. the "ENV" token approach > suggested in the commit comment.) > This change is also NOT listed in the version history for the plugin. > A typical failure stack trace follows. > Sending email to: real-addr...@mycompany.com $PROJECT_DEFAULT_RECIPIENTS > ERROR: Could not send email as a part of the post-build publishers. > javax.mail.SendFailedException: Invalid Addresses; > nested exception is: > com.sun.mail.smtp.SMTPAddressFailedException: 550 5.1.1 > <$PROJECT_DEFAULT_RECIPIENTS>: Recipient address rejected: User unknown in > local recipient table > at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196) > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584) > at javax.mail.Transport.send0(Transport.java:169) > at javax.mail.Transport.send(Transport.java:98) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:259) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:692) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:667) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:645) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) -- 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-11913) Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158713#comment-158713 ] Slide-O-Mix commented on JENKINS-11913: --- Just as an FYI, the release was put out without my knowledge, I was still working on making sure everything was fixed when the plugin was released by someone else. I apoligize for the problems and I am working on a full solution still. The ENV mechanism is easy, you can define environment variables in the global config, it does not take a special plugin or setup in the environment of the server. Just add an environment variable there with the list of emails, then you can use the ENV content token in the recipient field of any job. > Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs > -- > > Key: JENKINS-11913 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11913 > Project: Jenkins > Issue Type: Bug > Components: email-ext > Environment: occurs in email-ext plugin version 2.16 >Reporter: rvaughn >Assignee: Slide-O-Mix >Priority: Critical > Labels: email, email-ext, plugin > > Version 2.16 of the plugin removes support for the PROJECT_DEFAULT_RECIPIENTS > token, but leaves references to the token in the recipient lists for > previously-configured build jobs. This causes build to attempt to send email > to "$PROJECT_DEFAULT_RECIPIENTS" (literally), which of course fails. Delivery > to legitimate addresses fails at the same time. > This is a breaking change, as it requires manually editing all existing jobs > to remove the offending token reference. For installations with many jobs, > this could be overwhelming. In general, it's not a good idea to remove > functionality like this, therefore forcing your users to immediately > reconfigure to use your alternate method. (i.e. the "ENV" token approach > suggested in the commit comment.) > This change is also NOT listed in the version history for the plugin. > A typical failure stack trace follows. > Sending email to: real-addr...@mycompany.com $PROJECT_DEFAULT_RECIPIENTS > ERROR: Could not send email as a part of the post-build publishers. > javax.mail.SendFailedException: Invalid Addresses; > nested exception is: > com.sun.mail.smtp.SMTPAddressFailedException: 550 5.1.1 > <$PROJECT_DEFAULT_RECIPIENTS>: Recipient address rejected: User unknown in > local recipient table > at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196) > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584) > at javax.mail.Transport.send0(Transport.java:169) > at javax.mail.Transport.send(Transport.java:98) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:259) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:692) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:667) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:645) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) -- 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-11969) PROPFILE token does not properly close the property file
[ https://issues.jenkins-ci.org/browse/JENKINS-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158714#comment-158714 ] Joshua Niehus commented on JENKINS-11969: - This issue should be resolved by my Pull request and its subsequent requests on GitHub: https://github.com/jenkinsci/token-macro-plugin/pull/4 Fixing commit: https://github.com/jniehus/token-macro-plugin/commit/a1c32a353ea964ca9de2891524a6005a2a4da3e3 > PROPFILE token does not properly close the property file > > > Key: JENKINS-11969 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11969 > Project: Jenkins > Issue Type: Bug > Components: token-macro >Affects Versions: current > Environment: Jenkins 1.441 > token-macro-plugin 1.5.1 > Windows 7 x64 build slave running Sun JDK 1.6.0_20-b02 >Reporter: rvaughn >Assignee: Kohsuke Kawaguchi > Labels: macro, plugin, propfile, token, token-macro > > The current implementation of the PROPFILE token does not explicitly close > the property file after reading it. This can lead to the property file being > held open by the JVM for extended periods, long beyond the duration of the > build job. On my Windows 7 build slave, the file appears to be held open > indefinitely, and while testing the bug I once even saw two separate file > handles open against a single property file. The open file handles prevent > the file from being manipulated (deleted, moved, etc.) in Windows. > PropertyFromFileMacro.ReadProperty.call() should explicitly close the input > file immediately after calling Properties.load(). -- 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-11969) PROPFILE token does not properly close the property file
[ https://issues.jenkins-ci.org/browse/JENKINS-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158714#comment-158714 ] Joshua Niehus edited comment on JENKINS-11969 at 2/7/12 5:58 AM: - This issue should be resolved by my pull request and its subsequent commits on GitHub: https://github.com/jenkinsci/token-macro-plugin/pull/4 Fixing commit: https://github.com/jniehus/token-macro-plugin/commit/a1c32a353ea964ca9de2891524a6005a2a4da3e3 was (Author: joshua_niehus): This issue should be resolved by my Pull request and its subsequent requests on GitHub: https://github.com/jenkinsci/token-macro-plugin/pull/4 Fixing commit: https://github.com/jniehus/token-macro-plugin/commit/a1c32a353ea964ca9de2891524a6005a2a4da3e3 > PROPFILE token does not properly close the property file > > > Key: JENKINS-11969 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11969 > Project: Jenkins > Issue Type: Bug > Components: token-macro >Affects Versions: current > Environment: Jenkins 1.441 > token-macro-plugin 1.5.1 > Windows 7 x64 build slave running Sun JDK 1.6.0_20-b02 >Reporter: rvaughn >Assignee: Kohsuke Kawaguchi > Labels: macro, plugin, propfile, token, token-macro > > The current implementation of the PROPFILE token does not explicitly close > the property file after reading it. This can lead to the property file being > held open by the JVM for extended periods, long beyond the duration of the > build job. On my Windows 7 build slave, the file appears to be held open > indefinitely, and while testing the bug I once even saw two separate file > handles open against a single property file. The open file handles prevent > the file from being manipulated (deleted, moved, etc.) in Windows. > PropertyFromFileMacro.ReadProperty.call() should explicitly close the input > file immediately after calling Properties.load(). -- 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-12660) Fail to start the windows service when trying to launch slave node
Rico ZHANG created JENKINS-12660:
Summary: Fail to start the windows service when trying to launch
slave node
Key: JENKINS-12660
URL: https://issues.jenkins-ci.org/browse/JENKINS-12660
Project: Jenkins
Issue Type: Bug
Components: slave-setup
Affects Versions: current
Environment: Master : Redhat 5
Slave Node : Win7 x64
Reporter: Rico ZHANG
Assignee: Kohsuke Kawaguchi
We used to be able to launch the slave node successfully, but it did not work
since we upgraded the jenkins to latest version (1.449)
It doesn't dump any exception to the console, but I captured the output:
{noformat}
Connecting to 192.168.160.62
Checking if Java exists
java full version "1.7.0-b147"
Installing the Jenkins slave service
Copying jenkins-slave.exe
Copying slave.jar
Copying jenkins-slave.xml
Registering the service
ERROR: Failed to create a service: Status Invalid Service Account
...
{noformat}
--
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-12661) Claimed builds shown as unclaimed when multiple concurrent builds running for job
David Resnick created JENKINS-12661: --- Summary: Claimed builds shown as unclaimed when multiple concurrent builds running for job Key: JENKINS-12661 URL: https://issues.jenkins-ci.org/browse/JENKINS-12661 Project: Jenkins Issue Type: Bug Components: radiatorviewplugin Affects Versions: current Reporter: David Resnick Multiple concurrent builds of the same job may run if the "execute concurrent builds if necessary" checkbox is marked for a job. When there is a failed job that is claimed, the view shows the job as broken and claimed both if there is no running or a single running build of that type. If there are more than 1 running builds of that job, the view shows the job as broken and unclaimed (red). -- 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-4859) Slaves cannot be started using Windows Service on Windows Server 2008 x64
[
https://issues.jenkins-ci.org/browse/JENKINS-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158715#comment-158715
]
Alexis Morelle commented on JENKINS-4859:
-
There's a workaround less complicated thanks to Florian Vogler from Hudson-ci
wiki.
It can be applied to Microsoft Windows 7 too. :)
"This is caused by the TrustedInstaller concept of windows.
Solution I found so far:
Hudson requires full access to WBEM Scripting Locator
(HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}). Default for
administrators group is just read.
Change permissions for administrators group to "Full Control".
Launch 'regedit.exe' as 'Administrator'
Find the following registry key:
'HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}'
Right click and select 'Permissions'
Change owner to administrators group.
Change permissions for administrators group. Grant Full Control.
Change owner back to TrustedInstaller (user is "NT
Service\TrustedInstaller")
Restart Remote Registry Service"
> Slaves cannot be started using Windows Service on Windows Server 2008 x64
> -
>
> Key: JENKINS-4859
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4859
> Project: Jenkins
> Issue Type: Bug
> Components: master-slave
>Affects Versions: current
> Environment: Platform: All, OS: Windows XP
>Reporter: perostman
>Assignee: nuncanada
>
> Slave OS: Windows Server 2008 x64
> (This seems to be valid also for Vista64)
> Repro steps:
> 1. On the Hudson master, create a slave pointing to a machine running Windows
> Server 2008 x64 (This seem to be valid also for Vista64)
> 2. Choose to let Hudson control the slave as a Windows Service
> 3. Click the "Launch slave" button on the slave page on the Hudson Master
> Result: Hudson cannot control the slave. Stack trace below.
> Expected: That Hudson can control the slave properly.
> N.B. the slave adheres to the info on the following URL
> (http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM)
> Stack Trace:
>
> {noformat}
> Connecting to qa-w2k8x64-01
> Access is denied. See
> http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM
> for more information about how to resolve this.
> org.jinterop.dcom.common.JIException: Access is denied, please check whether
> the
> [domain-username-password] are correct. Also, if not already done please check
> the GETTING STARTED and FAQ sections in readme.htm. They provide information
> on
> how to correctly configure the Windows machine for DCOM access, so as to avoid
> such exceptions. [0x0005]
> at
> org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:297)
> at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:480)
> at org.jinterop.dcom.core.JIComServer.(JIComServer.java:427)
> at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
> at
> hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:107)
> at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:178)
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.jinterop.dcom.common.JIRuntimeException: Access is denied,
> please
> check whether the [domain-username-password] are correct. Also, if not already
> done please check the GETTING STARTED and FAQ sections in readme.htm. They
> provide information on how to correctly configure the Windows machine for DCOM
> access, so as to avoid such exceptions. [0x0005]
> at org.jinterop.winreg.IJIWinReg$createKey.read(IJIWinReg.java:459)
> at ndr.NdrObject.decode(NdrObject.java:19)
> at
> rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:138)
> at rpc.Stub.call(Stub.java:112)
> at
> org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:291)
> ... 10 more
> {noformat}
--
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-4929) windows 7 x86_64 slave fails to launch via DCOM
[
https://issues.jenkins-ci.org/browse/JENKINS-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158716#comment-158716
]
Alexis Morelle commented on JENKINS-4929:
-
There's a workaround less complicated thanks to Florian Vogler from Hudson-ci
wiki.
It can be applied to Microsoft Windows 7 too. :)
"This is caused by the TrustedInstaller concept of windows.
Solution I found so far:
Hudson requires full access to WBEM Scripting Locator
(HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}). Default for
administrators group is just read.
Change permissions for administrators group to "Full Control".
Launch 'regedit.exe' as 'Administrator'
Find the following registry key:
'HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}'
Right click and select 'Permissions'
Change owner to administrators group.
Change permissions for administrators group. Grant Full Control.
Change owner back to TrustedInstaller (user is "NT
Service\TrustedInstaller")
Restart Remote Registry Service"
> windows 7 x86_64 slave fails to launch via DCOM
> ---
>
> Key: JENKINS-4929
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4929
> Project: Jenkins
> Issue Type: Bug
> Components: master-slave
>Affects Versions: current
> Environment: Platform: PC, OS: Windows 7
>Reporter: evilchili
>Priority: Blocker
>
> This may not be a bug as I don't have another windows 7 box to test with, but
> it
> appears as though launching Windows 7 slaves via DCOM fails (this master can
> launch XP slaves via DCOM without incident). The slave has no firewall, the
> security policy for local accounts is set to 'classic', and the user is a
> member
> of the Administrators local group.
> Stack trace follows:
> Connecting to bursar
> Access is denied. See
> http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM
> for more information about how to resolve this.
> org.jinterop.dcom.common.JIException: Access is denied, please check whether
> the
> [domain-username-password] are correct. Also, if not already done please check
> the GETTING STARTED and FAQ sections in readme.htm. They provide information
> on
> how to correctly configure the Windows machine for DCOM access, so as to avoid
> such exceptions. [0x0005]
> at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:542)
> at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:458)
> at org.jinterop.dcom.core.JIComServer.(JIComServer.java:427)
> at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
> at
> hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:107)
> at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:178)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> Caused by: rpc.FaultException: Received fault. (unknown)
> at
> rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:142)
> at rpc.Stub.call(Stub.java:112)
> at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:538)
> ... 10 more
--
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
