[JIRA] [lotus-connections] (JENKINS-17811) Request Lotus Connections plugin to post to a community
Phil Rumble commented on JENKINS-17811 Request Lotus Connections plugin to post to a community The feature of posting status updates to communities is only available in Lotus Connections V4.0 onwards. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-17812) Add option to exclude certain email addresses
Jose Pedro Correia created JENKINS-17812 Add option to exclude certain email addresses Issue Type: New Feature Assignee: Alex Earl Components: email-ext Created: 01/May/13 9:18 AM Description: I would like to be able to exclude certain email addresses from being sent an email. My situation is I have the plugin set up to email committers when a job fails. The problem is that some committers are either phony users or people that are not responsible for maintaining code (they just committ some configuration files) and are not even aware of the Jenkins jobs. Long story short, I would like to be able to still email committers but also exclude certain users/email addresses from being sent an email. Project: Jenkins Priority: Minor Reporter: Jose Pedro Correia This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-17812) Add option to exclude certain email addresses
Alex Earl resolved JENKINS-17812 as Duplicate Add option to exclude certain email addresses JENKINS-17503 Change By: Alex Earl (01/May/13 11:07 AM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [warnings] (JENKINS-17762) Renaming the Clang parsers silently breaks Jenkins configs
SCM/JIRA link daemon commented on JENKINS-17762 Renaming the Clang parsers silently breaks Jenkins configs Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/WarningsPublisher.java src/test/java/hudson/plugins/warnings/parser/ParserRegistryIntegrationTest.java http://jenkins-ci.org/commit/warnings-plugin/475666b83c000825c518b5dfc1f60e7202d4ba66 Log: [FIXED JENKINS-17762] Replace old parser names with new names. During de-serialization the old parser names should be replaced with the new names otherwise the UI can't show the selected parser. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [warnings] (JENKINS-17762) Renaming the Clang parsers silently breaks Jenkins configs
Ulli Hafner commented on JENKINS-17762 Renaming the Clang parsers silently breaks Jenkins configs Ok, I finally fixed it. Actually, only the UI part was broken. All your jobs should still use the correct parser during processing... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [warnings] (JENKINS-17762) Renaming the Clang parsers silently breaks Jenkins configs
SCM/JIRA link daemon resolved JENKINS-17762 as Fixed Renaming the Clang parsers silently breaks Jenkins configs Change By: SCM/JIRA link daemon (01/May/13 12:17 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17774) Testing plugin in Windows fails with requested operation can't be performed on file with user-mapped section open
ikedam commented on JENKINS-17774 Testing plugin in Windows fails with requested operation can't be performed on file with user-mapped section open Failed to reproduce JENKINS-12647 with token-macro-plugin. It exactly fails in Windows, but seems have nothing to do with Jetty configuration. It cannot be solved by JENKINS-12647 patch, but can be fixed by calling System.gc(). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [perforce] (JENKINS-17652) Poll Exclude Files Too Aggressive on Blocking Builds?
Jason Davis resolved JENKINS-17652 as Fixed Poll Exclude Files Too Aggressive on Blocking Builds? Looks like v1.3.22 has solved the issue. Files that were once NOT triggering the build - it looks like because of the spaces - are now triggering builds. Thank you much for your help! Change By: Jason Davis (01/May/13 1:18 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17774) Testing plugin in Windows fails with requested operation can't be performed on file with user-mapped section open
ikedam commented on JENKINS-17774 Testing plugin in Windows fails with requested operation can't be performed on file with user-mapped section open Email-ext 2.18(based on Jenkins-1.428) always fails with hudson.plugins.emailext.ExtendedEmailPublisherMatrixTest. But it doesn't seem caused by JENKINS-12647. I cannot resolve the problem with a patch in JENKINS-12647. Root cause is: java.io.IOException: Unable to delete C:\Users\ikedam\AppData\Local\Temp\hudson3900114817529509895test\slave-slave0.log I have no idea to fix this problem. It rather seems like the problem in JENKINS-3018 (But this should be already fixed with Email-ext 2.18). This problem does not happen with latest Email-ext plugin (based on 1.480). And neither with latest Email-ext plugin unpached JENKINS-12647. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [copyartifact] (JENKINS-14266) Optional Copy Artifact build step fails if no specific build's build number is given
SCM/JIRA link daemon commented on JENKINS-14266 Optional Copy Artifact build step fails if no specific build's build number is given Code changed in jenkins User: Jesse Glick Path: src/test/java/hudson/plugins/copyartifact/SpecificBuildSelectorTest.java http://jenkins-ci.org/commit/copyartifact-plugin/8d3a3c84b3aa8d499adb77b4345badbe98e73f25 Log: JENKINS-14266 Confirming fix with a test. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17813) Jobs should have built in option to never clean workspace
Kevin Phillips created JENKINS-17813 Jobs should have built in option to never clean workspace Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: core Created: 01/May/13 5:32 PM Description: I am relatively new to Jenkins and was recently working on a new build configuration for my company when I discovered that Jenkins has a very odd feature I have never noticed before: it automatically tries to delete the working folder (ie: workspace) before performing the job operations. At best, this is an annoying feature and at worse it is a feature that can have extreme consequences if the content being deleted is irreplaceable. For example, the build configuration I was configuring was essentially an automation task that monitors a folder in SVN for changes and updates the local working folder on the build box with one or more custom script files required by our build infrastructure. Further, because these configuration scripts are global we need to store them in one of several different places including c:\Program Data, c:\users\local_build_user, etc. Given that these folders are system folders, often co-existing with other system critical files, you can imagine my surprise when Jenkins just magically started deleting anything and everything in these folders without my approval. So, on the one hand, I am very surprised that Jenkins would automatically delete anything without the sys admin explicitly telling the system to do so. In this vein I would suggest that it would be preferable to remove all such "automatic cleanup logic" from the application. On the other hand, I suspect this logic was put in place for some reason, and may be critical the behavior of the application. This being the case there should, at the very least, be an option on the configuration page for each job to turn off such logic in situations like mine. So, to summarize my build configuration, I have the following job parameters: Use custom workspace: c:\ Source code management: Subversion Repo URL: http:path_to_my_repo Local module directory: users\local_builder_profile Checkout strategy: Use 'svn update' as much as possible Build triggers: Poll SCM Schedule: H * * * * Then, as soon as I try to run this job for the first time Jenkins attempts to delete my entire user profile folder. It is also worth noting that I currently have a trivial configuration of Jenkins on one build PC (no distributed builds, agents, etc.) with minimal changes to the host OS to allow Jenkins to work. Also, I am using the latest version of Jenkins (1.512 at the moment). Finally, I did come across several other defects in your system related to this cleanup task, most notably JENKINS-3841. In the comment thread there in they mention the hudson.model.WorkspaceCleanupThread.disabled custom property as well. I have tried setting this to true but Jenkins' behavior seems to be unaffected. Environment: Windows 7 x64 Project: Jenkins Priority: Major Reporter: Kevin Phillips This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick assigned JENKINS-3107 to Jesse Glick "Advanced" section should be expanded if it is customized Change By: Jesse Glick (01/May/13 6:15 PM) Assignee: Jesse Glick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick started work on JENKINS-3107 "Advanced" section should be expanded if it is customized Change By: Jesse Glick (01/May/13 6:15 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick updated JENKINS-3107 "Advanced" section should be expanded if it is customized Change By: Jesse Glick (01/May/13 6:15 PM) URL: https://github.com/jenkinsci/jenkins/pull/768 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-13660) JSON fix for Opera in prototype.js probably not good anymore
evernat commented on JENKINS-13660 JSON fix for Opera in prototype.js probably not good anymore Is it still a problem in recent Jenkins version? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [jobgenerator] (JENKINS-17814) hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator
Walter Kacynski assigned JENKINS-17814 to Sylvain Benner hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator Change By: Walter Kacynski (01/May/13 6:22 PM) Assignee: Sylvain Benner This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [jobgenerator] (JENKINS-17814) hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator
Walter Kacynski created JENKINS-17814 hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator Issue Type: Bug Assignee: Unassigned Components: jobgenerator Created: 01/May/13 6:21 PM Description: 14:06:11 Started by upstream project "SND-Deploy-AA_Generate" build number 42 14:06:11 originally caused by: 14:06:11 Started by user 14:06:11 [EnvInject] - Loading node environment variables. 14:06:11 Building on master in workspace E:\JenkinsWAND\workspace\SND-Deploy-AA_Template 14:06:11 14:06:11 Deleting project workspace... 14:06:11 FATAL: hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator 14:06:11 java.lang.ClassCastException: hudson.model.FreeStyleProject cannot be cast to org.jenkinsci.plugins.jobgenerator.JobGenerator 14:06:11 at org.jenkinsci.plugins.jobgenerator.GeneratorRun$GeneratorImpl.cleanUp(GeneratorRun.java:427) 14:06:11 at hudson.model.Run.execute(Run.java:1620) 14:06:11 at org.jenkinsci.plugins.jobgenerator.GeneratorRun.run(GeneratorRun.java:206) 14:06:11 at hudson.model.ResourceController.execute(ResourceController.java:88) 14:06:11 at hudson.model.Executor.run(Executor.java:237) 14:06:11 at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66) Project: Jenkins Priority: Major Reporter: Walter Kacynski This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick updated JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Change By: Jesse Glick (01/May/13 6:31 PM) Labels: lts-candidate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
domi commented on JENKINS-3107 "Advanced" section should be expanded if it is customized I don't think this is a good idea... If we really want this, then i think the logical consequence would be to expand and remove the advanced buttons at all. But i think the advanced section is perfect to not have to over fill the UI. I think it would be much better to give the user an option to expand all advanced sections. In fact i fink the advanced sections should even be colapsable. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-13660) JSON fix for Opera in prototype.js probably not good anymore
Thomas Fürer resolved JENKINS-13660 as Cannot Reproduce JSON fix for Opera in prototype.js probably not good anymore Sorry, but I cannot reproduce it because the environment is not available anymore. I will close it (as "Cannot Reproduce"). If it is still a problem for someone, he will enter a new issue anyways. Change By: Thomas Fürer (01/May/13 6:38 PM) Status: Open Resolved Resolution: Cannot Reproduce This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ghprb] (JENKINS-17097) Changes are not present in builds started by a pull request
Ray Sennewald commented on JENKINS-17097 Changes are not present in builds started by a pull request Is this really needed anyway? Since the pull request will be initiated by the committer, and its status will be updated and comments added is that not notification enough? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick commented on JENKINS-3107 "Advanced" section should be expanded if it is customized The advanced sections are useful to not overload the UI with options you are never use. The problem is when you do use those options—or rather, someone on your team used those options without telling you and now you are trying to figure out why the build is behaving weirdly. Without this patch, there is no visual indication that anything in the advanced section has been touched. And even if you know/remember that there is something customized in a given advanced section, if you made that customization it is quite likely you are going to make changes to it in the future and want to always see it. Remember that the patch only expands those advanced sections with customizations. Others in the same form are left collapsed. So for example if you have a job with an Ant build step that defines some properties, that section will be shown in full, but there will still be a collapsed section at the top for display name and custom workspace. I would not argue against making advanced sections recollapsible, but that is an orthogonal RFE. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
domi commented on JENKINS-3107 "Advanced" section should be expanded if it is customized I do understand your points, but I just don't think this is a good solution. Some advanced sections are quite big e.g. for maven and now, just because I change a checkbox (like disable auto archiving) the whole section gets expanded. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Alex Earl commented on JENKINS-3107 "Advanced" section should be expanded if it is customized Why not change the appearance of the Advanced button if there are non-default modifications to the advanced settings? I also think it would be nice to be able to collapse an advanced section back down. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Balder VC commented on JENKINS-3107 "Advanced" section should be expanded if it is customized Appearance changing or just a small icon/sign that changes have been made there could be useful. Expanding by default, could get annoying if there are many advanced buttons. Usually you don't need all of the changed parts of a configuration page when adapting it to a new config. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
domi commented on JENKINS-3107 "Advanced" section should be expanded if it is customized +1 for the indication with an icon/sign This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick commented on JENKINS-3107 "Advanced" section should be expanded if it is customized To @domi’s example, I would argue that if you are disabling automatic archiving for a job then probably you are making other detailed changes to the job and might as well keep this section expanded. But this is a clearly a matter of taste. Changing the appearance of the Advanced button when customizations are present should be easy enough if that is the consensus UI. (Probably a bit easier than the current patch, actually, since you could make such a change retroactively after invoking the body, so there is no need for the j:mute hack.) Any thoughts on the actual appearance? Colorizing it in e.g. red would be easy enough, though it is not very accessible. Boldfacing the label would not show up well with all fonts. Adding an asterisk * may work but is not particularly discoverable; perhaps there is some broadly recognized Unicode character or icon that could be used to indicate that a field has edits. Glowing animation could be used but is again not accessible and could be seen as intrusive. The current code captures internal field names, not display labels, so the actual list of customized fields probably cannot be displayed. (Some controls provide a reliable way to get an associated display label, but others I think do 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 -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [active-directory] (JENKINS-17718) Active Directory Plugin Fails
Dan Dragut
commented on JENKINS-17718
Active Directory Plugin Fails
I believe this might be the change that broke it in 1.31 - might be because is escaping the "="?
https://github.com/jenkinsci/active-directory-plugin/commit/ef66cbbb2ce3f466b2d6468187b59e7088113077
The logger shows the "dn" variable unescaped (for="" but in fact it uses the escaped version to connect.
https://github.com/jenkinsci/active-directory-plugin/blob/ef66cbbb2ce3f466b2d6468187b59e7088113077/src/main/java/hudson/plugins/active_directory/ActiveDirectoryAuthenticationProvider.java
"active-directory-plugin / src / main / java / hudson / plugins / active_directory / ActiveDirectoryAuthenticationProvider.java"
// to do bind with DN as the user name, the flag must be 0
IADsUser usr;
try {
usr = (authentication==null
? dso.openDSObject("LDAP://"+ ldapEscape(dn), null, null, 0)
: dso.openDSObject("LDAP://"+ ldapEscape(dn), dn, password, 0))
.queryInterface(IADsUser.class);
} catch (ComException e) {
// this is failing
String msg = String.format("Incorrect password for %s for=%s: error=%08X", username, dn, e.getHRESULT());
LOGGER.log(Level.FINE, "Login failure: "+msg,e);
throw (BadCredentialsException)new BadCredentialsException(msg).initCause(e);
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [active-directory] (JENKINS-17718) Active Directory Plugin Fails
Dan Dragut
edited a comment on JENKINS-17718
Active Directory Plugin Fails
I believe this might be the change that broke it in 1.31 - might be because is escaping the "="?
https://github.com/jenkinsci/active-directory-plugin/commit/ef66cbbb2ce3f466b2d6468187b59e7088113077
The logger shows the "dn" variable unescaped (for="" but in fact it uses the escaped version to connect.
https://github.com/jenkinsci/active-directory-plugin/blob/ef66cbbb2ce3f466b2d6468187b59e7088113077/src/main/java/hudson/plugins/active_directory/ActiveDirectoryAuthenticationProvider.java
"active-directory-plugin / src / main / java / hudson / plugins / active_directory / ActiveDirectoryAuthenticationProvider.java"
// to do bind with DN as the user name, the flag must be 0
IADsUser usr;
try {
usr = (authentication==null
? dso.openDSObject("LDAP://"+ ldapEscape(dn), null, null, 0)
: dso.openDSObject("LDAP://"+ ldapEscape(dn), dn, password, 0))
.queryInterface(IADsUser.class);
} catch (ComException e) {
// this is failing
String msg = String.format("Incorrect password for %s for=%s: error=%08X", username, dn, e.getHRESULT());
LOGGER.log(Level.FINE, "Login failure: "+msg,e);
throw (BadCredentialsException)new BadCredentialsException(msg).initCause(e);
}
To revert to 1.30 download hpi, save into plugins dir and restart Jenkins.
http://updates.jenkins-ci.org/download/plugins/active-directory/
http://stackoverflow.com/questions/14950408/how-to-install-a-plugin-in-jenkins-manually
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [build-flow] (JENKINS-17815) Build Flow Plugin does not restrict node
craig pardey created JENKINS-17815 Build Flow Plugin does not restrict node Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 01/May/13 8:21 PM Description: I have a build flow that calls multiple sub-builds. The build flow is pinned to a particular node, but the sub-builds execute on a different node (usually master). The sub-builds should execute on the same node as the flow. Project: Jenkins Priority: Major Reporter: craig pardey This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Alex Earl commented on JENKINS-3107 "Advanced" section should be expanded if it is customized Unicode 2605 ★ Unicode 2606 ☆ There are also these glyphs available http://twitter.github.io/bootstrap/base-css.html#icons This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick commented on JENKINS-3107 "Advanced" section should be expanded if it is customized Neither of those characters says “outstanding edits” very clearly to me, and while icon-edit from Glyphicons looks reasonable, the license terms are a bit onerous. I am playing with document_edit.png which looks OK so far. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Balder VC commented on JENKINS-3107 "Advanced" section should be expanded if it is customized A unicode character that is outstanding enough to be a notification icon is not easy to find. Using a png that can be customised anyway some one want is perhaps a better option yes ☡ 2621 caution sign (curves ahead on road) or ⚠ 26A0 warning sign This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Just checked in a Jenkins dev build on 2008 R2 SP1 x64 using JDK 7u11 and the symlinks seemed to be fine from what I could see from Explorer and running dir. Send to » Compressed (zipped) folder did not work (the error message was generic). Jenkins did not report any error, either after the builds or after a restart. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Jesse Glick commented on JENKINS-3107 "Advanced" section should be expanded if it is customized Well try the current state in the branch—I think it looks decent (though I am hardly a master of UI). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [gui] (JENKINS-3107) "Advanced" section should be expanded if it is customized
Balder VC commented on JENKINS-3107 "Advanced" section should be expanded if it is customized As I'm not a UI master either for me it's fine. At least this way it's easy to see something changed. +1! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [envinject] (JENKINS-13348) EnvInject overriding WORKSPACE variable
Byron Brummer commented on JENKINS-13348 EnvInject overriding WORKSPACE variable The issue still exists. Jenkins 1.513, EnvInject 1.85 Same story as the original reporter: Downgrading EnvInject to 1.36 fixes it. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Mark Waite commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Is it possible that you're running with UAC disabled? I'm using JDK 7u21 and I consistently see that stack on multiple machines, though they all run with user account control enabled. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Mark Waite commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows http://superuser.com/questions/104845/permission-to-make-symbolic-links-in-windows-7 seems to suggest that creating symlinks as a normal user is not allowed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [android-emulator] (JENKINS-17816) SDK lookup from PATH looks for adb in {sdk}/tools folder (it has been moved).
Austyn Mahoney
created JENKINS-17816
SDK lookup from PATH looks for adb in {sdk}/tools folder (it has been moved).
Issue Type:
Bug
Assignee:
Christopher Orr
Components:
android-emulator
Created:
01/May/13 10:21 PM
Description:
Utils.getSdkRootFromPath() is testing for the existence of adb AND emulator in each directory in the path to determine if it is the Android SDK tools directory. The problem with this is is that in newer versions of the Android SDK, adb has been moved to the platform-tools directory. It will never find adb inside the same directory emulator is.
I suggest adding a check for adb_has_moved.txt if you must use the tools directory to determine the availability of the SDK in the PATH.
Project:
Jenkins
Labels:
plugin
android
Priority:
Major
Reporter:
Austyn Mahoney
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows I do not really know if I am running with UAC enabled or disabled, it is just a test installation. I know creating symlinks is only allowed under conditions on versions of Windows which support it, which is why PeepholePermalink.updateCache calls createSymlink and then checks resolveSymlink to see if it worked or not. The latter method is supposed to return null if the file is not a symlink, but it is assumed the file at least exists, and PeepholePermalink fails to check this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick assigned JENKINS-17681 to Jesse Glick LastSuccessful and LastStable symlinks are invalid under Windows Change By: Jesse Glick (01/May/13 10:36 PM) Assignee: Jesse Glick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick started work on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Change By: Jesse Glick (01/May/13 10:36 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [build-flow] (JENKINS-17817) Jenkins crashed when I stopped a job; all jobs running were killed
Lisa Reeber created JENKINS-17817 Jenkins crashed when I stopped a job; all jobs running were killed Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 01/May/13 11:07 PM Description: When I tried to stop one of my jobs running in Jenkins ver. 1.511, Jenkins immediately crashed and all of the running jobs were killed. Environment: Linux AMD 64 - 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Project: Jenkins Labels: jenkins Priority: Major Reporter: Lisa Reeber This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [android-emulator] (JENKINS-17517) Support for dynamic skins (a la JellyBean devices)
Andrew Zellman commented on JENKINS-17517 Support for dynamic skins (a la JellyBean devices) Christopher, any news on this? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Mark Waite commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows I just checked on a Windows 8 machine and confirmed that the command program "mklink.exe" requires administrator privileges to create a file symlink. The command "mklink x.jar classworlds.jar" fails with the message: You do not have sufficient privilege to perform this operation. If I run that same command from a window that was started with Administrator privileges, then the link is created as expected. http://technet.microsoft.com/library/cc766301.aspx gives the explanation that creating symlinks may expose security bugs in programs not designed to handle symlinks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Jesse Glick commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows In an administrator account, could reproduce the problem in a unit test. Why this does not happen when I actually run Jenkins, I am not sure, but perhaps because the test’s working directory is not on an NTFS volume. At any rate, that was enough to test my hypothesis and implement a fix; and I tried running in a regular user account and it seems to work. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
SCM/JIRA link daemon commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/Util.java core/src/main/java/jenkins/model/PeepholePermalink.java http://jenkins-ci.org/commit/jenkins/3c2b50ecfe1c58f64b32d30a3f96e647671f7d03 Log: [FIXED JENKINS-17681] Do not try to call resolveSymlink on a nonexistent link as you will just get an IOException, breaking peephole permalinks in some Windows environments. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
SCM/JIRA link daemon resolved JENKINS-17681 as Fixed LastSuccessful and LastStable symlinks are invalid under Windows Change By: SCM/JIRA link daemon (02/May/13 12:15 AM) Status: In Progress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
SCM/JIRA link daemon commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Code changed in jenkins User: Jesse Glick Path: core/src/main/java/jenkins/model/PeepholePermalink.java core/src/test/java/jenkins/model/PeepholePermalinkTest.java http://jenkins-ci.org/commit/jenkins/00d5e38759d08fa89ef366fd430e900f4138f0af Log: JENKINS-17681 Set up a test which passes on Unix but fails on Windows when symlinks are enabled on the platform but disabled for the current user. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [active-directory] (JENKINS-17692) Active Directory Plugin - Fails to retreive users with swedish characters in full name
Kohsuke Kawaguchi resolved JENKINS-17692 as Fixed Active Directory Plugin - Fails to retreive users with swedish characters in full name This problem was fixed in 1.32. Change By: Kohsuke Kawaguchi (02/May/13 12:59 AM) Status: Open Resolved Assignee: Kohsuke Kawaguchi Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
dogfood commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Integrated in jenkins_main_trunk #2505 JENKINS-17681 Set up a test which passes on Unix but fails on Windows when symlinks are enabled on the platform but disabled for the current user. (Revision 00d5e38759d08fa89ef366fd430e900f4138f0af) [FIXED JENKINS-17681] Do not try to call resolveSymlink on a nonexistent link as you will just get an IOException, breaking peephole permalinks in some Windows environments. (Revision 3c2b50ecfe1c58f64b32d30a3f96e647671f7d03) Result = SUCCESS Jesse Glick : 00d5e38759d08fa89ef366fd430e900f4138f0af Files : core/src/test/java/jenkins/model/PeepholePermalinkTest.java core/src/main/java/jenkins/model/PeepholePermalink.java Jesse Glick : 3c2b50ecfe1c58f64b32d30a3f96e647671f7d03 Files : core/src/main/java/jenkins/model/PeepholePermalink.java core/src/main/java/hudson/Util.java changelog.html This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17818) Custom workspace folders should be relative to the global workspace folder
Kevin Phillips created JENKINS-17818 Custom workspace folders should be relative to the global workspace folder Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: core Created: 02/May/13 2:11 AM Description: Consider the following use case: Jenkins is installed in a folder on the main OS drive, C:\some_folder A secondary, larger "data" drive exists on the system, D:, and we want to set that to be the primary location for our job / build / workspace folders (e.g.: d:\builds) Further, since we have a non-trivial build configuration we need to configure several jobs in such a way that they share the same root working folder, with subsets of the projects stored in subfolders (e.g.: modules). Now, intuitively one might think that the best way to manage this configuration would be to set up each related job with the same root folder via the "custom workspace folder" (as found under the advanced job configuration section). Also, to avoid having duplicated absolute paths in each job configuration one might think it intuitive to use relative paths for this property, expecting that the relative path would be relative to the custom root workspace folder setup earlier. However, for some reason, when one enters a relative path in this custom workspace folder field, it is expected to be relative to JENKINS_HOME. I find this extremely non-intuitive to say the least. This behavior is also inconsistent with the interpretation of the "local module folder" setting in the SVN plugin (which is a path relative to the workspace) and the shell script build actions, which also assume that the working folder is the workspace folder and any relative paths used in the scripts are relative to the workspace. As such I would highly recommend updating Jenkins such that relative paths entered in the "custom workspace" field in a job be changed so they are relative to the root workspace folder instead of relative to the Jenkins home folder. Environment: Windows 7 x64 Project: Jenkins Priority: Major Reporter: Kevin Phillips This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-17819) The SVN local module folder should be relative to the workspace of the job rather than the root workspace
Kevin Phillips created JENKINS-17819 The SVN local module folder should be relative to the workspace of the job rather than the root workspace Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: subversion Created: 02/May/13 2:21 AM Description: The help text associated with the "local module directory" field states: Specify a local directory (relative to the workspace root) where this module is checked out. If left empty, the last path component of the URL is used as the default, just like the svn CLI. A single period (.) may be used to check out the project directly into the workspace rather than into a subdirectory. I can't imaging a situation where one would ever want to check out a code module into a custom sub-folder that is found relative to the "workspace root" instead of the workspace folder being used for the current job. Also, I would intuitively expect this relative path to respect any settings applied to the "custom workspace" field under the advanced project options area as well, so if specified the local module folder would be relative to whatever the custom workspace path resolves to (e.g.: whether it has an absolute or relative path). Environment: Windows 7 x64 Project: Jenkins Priority: Major Reporter: Kevin Phillips This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-13779) Git Publisher (tagging) can't work with multipe SCM (ClassCastException: org.jenkinsci.plugins.multiplescms.MultiSCM cannot be cast to hudson.plugins.git.GitSCM)
Ajith Thampi commented on JENKINS-13779 Git Publisher (tagging) can't work with multipe SCM (ClassCastException: org.jenkinsci.plugins.multiplescms.MultiSCM cannot be cast to hudson.plugins.git.GitSCM) Any update on this fix? I am facing the exact same issue with MultiSCM. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [master-slave] (JENKINS-6188) When a build is aborted, Hudson does not kill all the descendant processes recursively to avoid run-away processes on the Slave Build machines.
Tully Foote commented on JENKINS-6188 When a build is aborted, Hudson does not kill all the descendant processes recursively to avoid run-away processes on the Slave Build machines. We've had the same issue using pbuilder for several years. We're running 1.513 now, but we've been seeing this issue for a long time. Jobs end up with orphaned process trees like this: root 32018 0.0 0.0 53788 1524 ?S08:50 0:00 sudo pbuilder execute --basetgz /var/cache/pbuilder/jenkins_tools.precise.am root 32019 0.0 0.1 12824 1812 ?S08:50 0:00 _ /bin/bash /usr/sbin/pbuilder execute --basetgz /var/cache/pbuilder/jenki root 10649 0.0 0.0 9424 1256 ?S08:50 0:00 _ /bin/bash -ex /runscript doc root 10656 0.1 1.3 75456 24148 ?S08:50 0:36 | _ python /home/rosbuild/hudson/workspace/doc-fuerte-tum/jenkins_sc root 9009 0.0 0.0 9768 1692 ?S16:55 0:00 | _ bash -c source /opt/ros/fuerte/setup.bash && export PYTHONPA root 9026 1.1 1.3 61092 22904 ?S16:55 0:00 | _ /usr/bin/python /usr/local/bin/rosdoc_lite /home/rosbuil root 9027 52.0 18.6 350096 327324 ? D16:55 0:43 | _ doxygen /tmp/tmpwC1LwG root 9365 0.0 0.0 4308 352 ?S16:56 0:00 _ sleep 5s Where the pbuilder process used to be a subprocess of the script being run by jenkins. However you can see that jenkins is in a separate process tree: root 747 0.0 0.0 49948 244 ?Ss Apr16 0:01 /usr/sbin/sshd -D root 12760 0.0 0.0 92224 372 ?Ss Apr30 0:00 _ sshd: rosbuild [priv] rosbuild 12904 0.0 0.0 92408 528 ?SApr30 0:50 | _ sshd: rosbuild@notty rosbuild 12918 0.0 0.0 12296 228 ?Ss Apr30 0:00 | _ bash -c cd '/home/rosbuild/hudson' && java -jar slave.jar rosbuild 12919 0.1 4.4 1598760 77928 ? Sl Apr30 1:55 | _ java -jar slave.jar root 9084 0.0 0.2 90164 4052 ?Ss 16:56 0:00 _ sshd: root@pts/3 root 9281 0.5 0.3 24056 5300 pts/3Ss 16:56 0:00 _ -bash root 9366 0.0 0.0 18128 1200 pts/3R+ 16:56 0:00 _ ps auxf We're running a linux master and slaves with SSH Slaves plugin 0.23 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [master-slave] (JENKINS-6188) When a build is aborted, Hudson does not kill all the descendant processes recursively to avoid run-away processes on the Slave Build machines.
Tully Foote edited a comment on JENKINS-6188 When a build is aborted, Hudson does not kill all the descendant processes recursively to avoid run-away processes on the Slave Build machines. We've had the same issue using pbuilder for several years. We're running 1.513 now, but we've been seeing this issue for a long time. Jobs end up with orphaned process trees like this: root 32018 0.0 0.0 53788 1524 ?S08:50 0:00 sudo pbuilder execute --basetgz /var/cache/pbuilder/jenkins_tools.precise.am root 32019 0.0 0.1 12824 1812 ?S08:50 0:00 \_ /bin/bash /usr/sbin/pbuilder execute --basetgz /var/cache/pbuilder/jenki root 10649 0.0 0.0 9424 1256 ?S08:50 0:00 \_ /bin/bash -ex /runscript doc root 10656 0.1 1.3 75456 24148 ?S08:50 0:36 | \_ python /home/rosbuild/hudson/workspace/doc-fuerte-tum/jenkins_sc root 9009 0.0 0.0 9768 1692 ?S16:55 0:00 | \_ bash -c source /opt/ros/fuerte/setup.bash && export PYTHONPA root 9026 1.1 1.3 61092 22904 ?S16:55 0:00 | \_ /usr/bin/python /usr/local/bin/rosdoc_lite /home/rosbuil root 9027 52.0 18.6 350096 327324 ? D16:55 0:43 | \_ doxygen /tmp/tmpwC1LwG root 9365 0.0 0.0 4308 352 ?S16:56 0:00 \_ sleep 5s Where the pbuilder process used to be a subprocess of the script being run by jenkins. However you can see that jenkins is in a separate process tree: root 747 0.0 0.0 49948 244 ?Ss Apr16 0:01 /usr/sbin/sshd -D root 12760 0.0 0.0 92224 372 ?Ss Apr30 0:00 \_ sshd: rosbuild [priv] rosbuild 12904 0.0 0.0 92408 528 ?SApr30 0:50 | \_ sshd: rosbuild@notty rosbuild 12918 0.0 0.0 12296 228 ?Ss Apr30 0:00 | \_ bash -c cd '/home/rosbuild/hudson' && java -jar slave.jar rosbuild 12919 0.1 4.4 1598760 77928 ? Sl Apr30 1:55 | \_ java -jar slave.jar root 9084 0.0 0.2 90164 4052 ?Ss 16:56 0:00 \_ sshd: root@pts/3 root 9281 0.5 0.3 24056 5300 pts/3Ss 16:56 0:00 \_ -bash root 9366 0.0 0.0 18128 1200 pts/3R+ 16:56 0:00 \_ ps auxf We're running a linux master and slaves with SSH Slaves plugin 0.23 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17820) Deadlock between a folder copy and job deletion
Vincent Latombe created JENKINS-17820 Deadlock between a folder copy and job deletion Issue Type: Bug Assignee: Unassigned Attachments: threaddump.txt Components: core Created: 02/May/13 5:08 AM Description: This deadlock blocks any attempt of saving job configuration, the only solution is to restart the instance. Environment: Jenkins 1.512 Jenkins Folders plugin 3.6 Project: Jenkins Priority: Major Reporter: Vincent Latombe This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17820) Deadlock between a folder copy and job deletion
Vincent Latombe updated JENKINS-17820 Deadlock between a folder copy and job deletion Change By: Vincent Latombe (02/May/13 5:09 AM) Description: This deadlock blocks any attempt of saving job configuration, the only solution is to restart the instance. See threads :- "Handling POST /view/JCP%20Folders/createItem : RequestHandlerThread[#880]" - Thread t@63757- "Handling POST /view/SDX%20management%20View/createItem : RequestHandlerThread[#784]" - Thread t@57037 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17821) Manual triggering of builds returned 404 error when accessing base build
Emma Bao updated JENKINS-17821 Manual triggering of builds returned 404 error when accessing base build Change By: Emma Bao (02/May/13 5:30 AM) Component/s: core Component/s: jenkins-jira-issue-updater This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17821) Manual triggering of builds returned 404 error when accessing base build
Emma Bao updated JENKINS-17821 Manual triggering of builds returned 404 error when accessing base build Change By: Emma Bao (02/May/13 5:32 AM) Environment: Jenkins 1.510 Description: By clicking the "build now" link with admin user logon, the builds were triggered with the same error as below until the 3rd time successful build.The anonymous user also has been given read to overall privilege.10:36:46 Starting download of base build...10:36:46 base_url= http://build.xxx.com/job/[FullBuildJobName]/[BuildNumber]/artifact10:36:46 download_url= http://build.xxx.com/job/[FullBuildJobName]/[BuildNumber]/artifact/[FullBuildSourceCodeFileName].zip10:36:46 --2013-05-01 17 10 :36:47-- http://build.xxx.com/job/[FullBuildJobName]/[BuildNumber]/artifact/[FullBuildSourceCodeFileName].zip10:36:46 Resolving build.xxx.com... aaa.bbb.cc.dd[ip address]10:36:51 Connecting to build.xxx.com|aaa.bbb.cc.dd|:80... connected.10:36:51 HTTP request sent, awaiting response... 404 Not Found10:36:51 2013-05-01 17:36:52 ERROR 404: Not Found. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17821) Manual triggering of builds returned 404 error when accessing base build
Emma Bao updated JENKINS-17821 Manual triggering of builds returned 404 error when accessing base build Change By: Emma Bao (02/May/13 5:55 AM) Description: By clicking the "build now" link with admin user logon, the builds were triggered with the same error as below until the 3rd time successful build.The anonymous user also has been given read to overall privilege.10:36:46 Starting download of base build...10:36:46 base_url= http:// build.xxx.com /job/[FullBuildJobName]/[BuildNumber]/artifact10:36:46 download_url= http:// build.xxx.com /job/[FullBuildJobName]/[BuildNumber]/artifact/[FullBuildSourceCodeFileName].zip10:36:46 --2013-05-01 10:36:47-- http:// build.xxx.com /job/[FullBuildJobName]/[BuildNumber]/artifact/[FullBuildSourceCodeFileName].zip10:36:46 Resolving build . xxx . com . xxx . xxx . aaa 45 . bbb.cc.dd[ip address] 69 10:36:51 Connecting to build.xxx.com| aaa xxx . bbb xxx . cc 45 . dd 69 |: 80 8081 ... connected.10:36:51 HTTP request sent, awaiting response... 404 Not Found10:36:51 2013-05-01 17:36:52 ERROR 404: Not Found. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ghprb] (JENKINS-16242) Github pull request builder - branch to merged before build
Ray Sennewald updated JENKINS-16242 Github pull request builder - branch to merged before build Change By: Ray Sennewald (02/May/13 6:43 AM) Component/s: ghprb This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [mercurial] (JENKINS-17649) Mercurial cache doesn't work if master and slave run on different OS
Dirk Heinrichs commented on JENKINS-17649 Mercurial cache doesn't work if master and slave run on different OS Ah, OK. Thank you for the clarification. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [ghprb] (JENKINS-16242) Github pull request builder - branch to merged before build
Ray Sennewald commented on JENKINS-16242 Github pull request builder - branch to merged before build I take it the reporter means he opens a pull request lets say from a fork with feature branch named feature01 to original repo's master branch. He wants the pull request builder plugin to test the pull request by testing against the PR merged into its destination (in this case merging PR which is created from feature01 to original repo's master branch) and attach the status of that merged pull request build. The comment should also indicated what was merged for the testing. This would be similar to the way Travis CI does this: http://travis-pr.herokuapp.com/image/slides/travisbot.png . With the addition for this, we would actually test the merged version, rather than just the fork or feature branch. Thus, we also take into account changes made upstream after the repository has been forked. FWIW this should only be possible if the Automerge button is available on the pull request. Perhaps we could have a global option in the plugin to allow for this, and you can override it in any specific job if you should so choose? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
