[JIRA] (JENKINS-16232) !build abort works even if bot doesn't have cancel permissions
SCM/JIRA link daemon commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions Code changed in jenkins User: Christoph Kutzinski Path: src/main/java/hudson/plugins/im/bot/AbortCommand.java src/main/java/hudson/plugins/im/bot/AbstractSingleJobCommand.java src/main/java/hudson/plugins/im/bot/CommentCommand.java http://jenkins-ci.org/commit/instant-messaging-plugin/5889fcc93a959a70b447cbaf4d504bf1edec8d34 Log: Check permissions for abort and command commands FIXED JENKINS-16232 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11154) Repository_depth_option variable is missing from Source Code Managments
Peter Ross commented on JENKINS-11154 Repository_depth_option variable is missing from Source Code Managments The following pull request implements this feature. https://github.com/jenkinsci/subversion-plugin/pull/29 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16232) !build abort works even if bot doesn't have cancel permissions
kutzi commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions Thanks for pointing this out! Can you append the message where the bot complains that it couldn't abort the build? I couldn't see any permission checking there and wonder where this message comes from. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-777) The need for Subversion command line options.
Peter Ross commented on JENKINS-777 The need for Subversion command line options. The following pull request implements both --ignore-externals and --set-depth options. https://github.com/jenkinsci/subversion-plugin/pull/29 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16233) EnvInject plugin using a cached value for ${WORKSPACE}
Bob Silverberg
created JENKINS-16233
EnvInject plugin using a cached value for ${WORKSPACE}
Issue Type:
Bug
Assignee:
Gregory Boissinot
Components:
envinject
Created:
01/Jan/13 3:07 PM
Description:
Starting yesterday, the EnvInject plugin seems to suddenly start using a cached value for ${WORKSPACE}. We have the following value in "Properties Content" under "Inject environment variables to the build process":
PATH=${WORKSPACE}/.env/bin:$PATH
When working properly, in the console output this appears as:
EnvInject - Injecting as environment variables the properties content
PATH=${WORKSPACE}/.env/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin
Over the past couple of days this has suddenly started appearing as:
EnvInject - Injecting as environment variables the properties content
PATH=/Users/Shared/Jenkins/Home/jobs/bidpom.stage/workspace/.env/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin
Which is using a workspace path from another job. This causes this job, and all other jobs, to fail. If I restart Jenkins the problem goes away, for awhile, but at some point that exact same path starts getting used by the EnvInject plugin again. This cycle has happened 4 times over the past couple of days, where jobs will run fine for awhile and then suddenly start failing because the path injected changes from:
${WORKSPACE}/.env/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin
to:
/Users/Shared/Jenkins/Home/jobs/bidpom.stage/workspace/.env/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin
When this first happened we downgraded the plugin from 1.78 to 1.77 but this hasn't addressed the problem.
Any help anyone can provide would be greatly appreciated.
Project:
Jenkins
Priority:
Major
Reporter:
Bob Silverberg
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16074) Content of AndroidManifest.xml not shown in Android Lint Plugin
Joris van der Pol commented on JENKINS-16074 Content of AndroidManifest.xml not shown in Android Lint Plugin Hi, I'm using the Lint target as provided in the build.xml (Android SDK Tools 21.0.1). A generated build.xml file which imports the build.xml of the SDK installation resides in the same directory as the AndroidManifest.xml. I noticed that the Source Folder is set to (none) in this case. I'll mail you the generated XML file. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16074) Content of AndroidManifest.xml not shown in Android Lint Plugin
Joris van der Pol edited a comment on JENKINS-16074 Content of AndroidManifest.xml not shown in Android Lint Plugin Hi, I'm using the Lint target as provided in the build.xml (Android SDK Tools 21.0.1). A generated build.xml file which imports the build.xml of the SDK installation resides in the same directory as the AndroidManifest.xml. I noticed that the Source Folder is set to (none) in this case. I'll mail you the generated Lint XML file. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16232) !build abort works even if bot doesn't have cancel permissions
jephir
updated JENKINS-16232
!build abort works even if bot doesnt have cancel permissions
Change By:
jephir
(01/Jan/13 6:22 PM)
Description:
Issuingthe!buildabortcommandworksevenifthebotdoesnthavecancelpermissionsinJenkins.Thebotcomplainsthatitcouldntabortthebuild,buttheabortstillsucceeds.Thiscanbetestedbygivingthebotonlyreadpermissions.
{quote}Jephir!buildabortmy_projectBuildBotJephir:couldntabortmy_project.Idontknowwhythishappened.{quote}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16232) !build abort works even if bot doesn't have cancel permissions
jephir commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions This is the error message: Jephir !build abort my_project BuildBot Jephir: couldn't abort my_project. I don't know why this happened. The bot complains it couldn't abort, but looking in Jenkins, it had still succeeded in aborting the build even without cancel permissions. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16074) Content of AndroidManifest.xml not shown in Android Lint Plugin
Christopher Orr commented on JENKINS-16074 Content of AndroidManifest.xml not shown in Android Lint Plugin That file looks ok, and everything works fine when I use your Lint XML file, or generate one myself with "ant lint". Maybe it's a Windows thing..? Could you possibly attach or send the $JENKINS_HOME/jobs/$JOB_NAME/lastSuccessful/android-lint-issues.xml file? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16232) !build abort works even if bot doesn't have cancel permissions
kutzi commented on JENKINS-16232 !build abort works even if bot doesnt have cancel permissions Thanks, that pointed me to another minor bug that the bug would always print this - regardless if the abort succeeded or not. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16234) Plugin does not currently work for Clearcase Base
Steve Davidson created JENKINS-16234 Plugin does not currently work for Clearcase Base Issue Type: Bug Affects Versions: current Assignee: Steve Davidson Components: clearcase Created: 02/Jan/13 2:06 AM Description: When attempting to use Base Clearcase on a Linux Slave to access a snapshot, the parameters "stgloc -auto" are added to the cleartool command line. This is ONLY appropriate for Clearcase UCM, NOT for Base Clearcase. By always adding these parameters, Base Clearcase will error/fail on View Creation. Note that -vws is also not appropriate in this scenario. Due Date: 31/Jan/13 12:00 AM Environment: Linux Slave (MS Master) Project: Jenkins Labels: plugin scm clearcase base Priority: Major Reporter: Steve Davidson This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16234) Plugin does not currently work for Clearcase Base
Steve Davidson started work on JENKINS-16234 Plugin does not currently work for Clearcase Base Change By: Steve Davidson (02/Jan/13 2:22 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16234) Plugin does not currently work for Clearcase Base
Steve Davidson commented on JENKINS-16234 Plugin does not currently work for Clearcase Base A fix has been committed and a Pull Request Generated. In addition, I've already deployed the fix for a Team using Base Clearcase and it's working fine for them. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12046) TestNG shouldn't look for result files if build was aborted
nalin_makar commented on JENKINS-12046 TestNG shouldnt look for result files if build was aborted Kutzi, I'll make the change to not look for results in case build is aborted. And, continue looking for reports in case of build failures. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16110) testng suite support
nalin_makar commented on JENKINS-16110 testng suite support Chris, Could you attach a sample testng-results.xml file that you are running into this issue with? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15157) Failure in @DataProvider method is not reported and build stays SUCCESS
nalin_makar resolved JENKINS-15157 as Not A Defect Failure in @DataProvider method is not reported and build stays SUCCESS Please configure your maven or ant task to fail on testng failures. This is not a testng plugin issue. Change By: nalin_makar (02/Jan/13 5:33 AM) Status: Open Resolved Resolution: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
