[JIRA] [parameterized-trigger-plugin] (JENKINS-26050) Workflow integration for Parameterized Trigger
Title: Message Title Markus commented on JENKINS-26050 Re: Workflow integration for Parameterized Trigger Any one that has a workaround for the lack of Workflow integration for Parameterized Trigger? The triggering can be solved, but I have problems passing parameters to a downstream Workflow without the Parameterized Trigger plugin. (Who actually triggered me?) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger-plugin] (JENKINS-26050) Workflow integration for Parameterized Trigger
Title: Message Title Markus edited a comment on JENKINS-26050 Re: Workflow integration for Parameterized Trigger - AnyonethathasaworkaroundforthelackofWorkflowintegrationforParameterizedTrigger?Thetriggeringcanbesolved,butIhaveproblemspassingparameterstoadownstreamWorkflowwithouttheParameterizedTriggerplugin.(Whoactuallytriggeredme?) -Edit:Myworkaroundseemstobesetupthedownstreamworkflowjobasanormalparametrizedjob.Theseparametersareavailabledirectlyasvariables.I'llthenusetheRESTAPIandcurltotriggerthedownstreamjobwithparameters. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger-plugin] (JENKINS-18536) Remove downstream job from queue before new triggers
Markus updated JENKINS-18536 Remove downstream job from queue before new triggers Change By: Markus (29/Apr/15 7:23 AM) Description: Giventwojobs:*Downstream,whichhasa60squietperiod*Upstream,whichtriggersaparameterizedbuildonDownstreamNow,ifyouquicklytriggerUpstream3times,thentherewillbe3Downstreamjobsinthequeue.Theywillthenallrun.WewouldlikeparameterizedtriggeringincombinationwithdownstreamquietperiodtobehavesortofliketheSVNquietperiodbehaves:IfUpstreamistriggeredmultipletimes,thenonlythelasttriggeredDownstreamwillremaininthequeue. Thiswillhelpwhenyouhavelimitedverificationresourcesduringdevelopmentandwouldliketorunabesteffortapproach.Itwillpreventthequeuefromcontinuouslygrowing. Summary:BeforeUpstreamtriggersDownstream,UpstreamshouldremoveanyinstancesofDownstreamfromthequeue.Thisshouldofcoursebeanoptionandnotthedefaultbehavior. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-directory-plugin] (JENKINS-13058) E-mail to individuals who broke the build is sent to wrong address
Markus closed JENKINS-13058 as Cannot Reproduce E-mail to individuals who broke the build is sent to wrong address I'm sorry, but we do not see this issue anymore and have not for years. I'll therefore close this as cannot reproduce since I as reporter cannot reproduce it. Given the time that has passed since I reported this, I suspect your problem would have a different root cause. (If this is a very wrong issue tracking methodology, then please let me know. I'll then reopen it.) Change By: Markus (23/Apr/15 6:14 AM) Status: Open Closed Resolution: CannotReproduce This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [walldisplay-plugin] (JENKINS-27506) Too many yellow dots on Wall Display
Markus commented on JENKINS-27506 Too many yellow dots on Wall Display Thank you very much! I'll test it out after our next upgrade This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [walldisplay-plugin] (JENKINS-27506) Too many yellow dots on Wall Display
Markus created JENKINS-27506 Too many yellow dots on Wall Display Issue Type: Bug Assignee: Christian Pelster Attachments: dots.PNG Components: walldisplay-plugin Created: 19/Mar/15 1:23 PM Description: We often have quite a few jobs in the queue. That is normal operation. And we use this very nice plugin on our monitors. Problem is that when a job is in the back of the queue, get get up to 15 yellow dots. They often block major parts of the text: Could maybe the maximum number of yellow dots be limited, or add a feature where we can turn the dots off? Environment: Jenkins ver. 1.580.2 Wall Display Master Project 0.6.27 Project: Jenkins Priority: Minor Reporter: Markus This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [walldisplay-plugin] (JENKINS-27506) Too many yellow dots on Wall Display
Markus updated JENKINS-27506 Too many yellow dots on Wall Display Change By: Markus (19/Mar/15 1:26 PM) Description: Weoftenhavequiteafewjobsinthequeue.Thatisnormaloperation.Andweusethisverynicepluginonourmonitors.Problemisthatwhenajobisinthebackofthequeue,getgetupto15yellowdots.Theyoftenblockmajorpartsofthetext:!dots.PNG |thumbnail !Couldmaybethemaximumnumberofyellowdotsbelimited,oraddafeaturewherewecanturnthedotsoff? (Ishouldadd-wehavehundredsofjobssotheviewusedtogeneratethisscreenonlyshowsjobsthathavefailedoneofthelastXbuilds.) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion-plugin] (JENKINS-22542) Subversion polling not work with externals or variables in URL - E200015: No credential to try.
Markus commented on JENKINS-22542 Subversion polling not work with externals or variables in URL - E200015: No credential to try. We're also seeing this problem after upgrading to 2.5. Had to downgrade to 2.4.5. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [claim-plugin] (JENKINS-27144) View Job Filter plugin should support the Claim plugin
Markus updated JENKINS-27144 View Job Filter plugin should support the Claim plugin (edit: added claim-plugin component and modified the Summary) Change By: Markus (26/Feb/15 12:42 PM) Summary: Supportfor ViewJobFilterpluginshouldsupport theClaimplugin Description: Itwouldbegreatif we theViewJobFilterplugin couldaddafilterontheClaimstatus,asprovidedbytheClaimplugin:https://wiki.jenkins-ci.org/display/JENKINS/Claim+pluginThispluginmakesitpossibleforuserstotellthesystem/otherusersthattheyareworkingonafixforthefailingjob.Itwouldimproveourviewsifwethencouldfilteroutfailingjobsthatsomeoneislookinginto.ItcouldbeaddedasacheckboxtotheJobStatusfilter,oraseparatefilterClaimstatuscouldbeadded.TheClaimstatusisshownintheRESTAPI,soitshouldbeexposedsomehowanavailabletoyou. Component/s: claim-plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [view-job-filters-plugin] (JENKINS-27144) Support for the Claim plugin
Markus created JENKINS-27144 Support for the Claim plugin Issue Type: Improvement Assignee: Jacob Robertson Components: view-job-filters-plugin Created: 26/Feb/15 12:41 PM Description: It would be great if we could add a filter on the Claim status, as provided by the Claim plugin: https://wiki.jenkins-ci.org/display/JENKINS/Claim+plugin This plugin makes it possible for users to tell the system/other users that they are working on a fix for the failing job. It would improve our views if we then could filter out failing jobs that someone is looking into. It could be added as a check box to the Job Status filter, or a separate filter "Claim status" could be added. The Claim status is shown in the REST API, so it should be exposed somehow an available to you. Project: Jenkins Priority: Minor Reporter: Markus This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [claim-plugin] (JENKINS-26364) Expose claimed failing tests via the REST API
Markus commented on JENKINS-26364 Expose claimed failing tests via the REST API It is already exposed, is it not? JENKINS-6145 (and we're using it all the time, but only the XML REST API) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter-plugin] (JENKINS-24618) Absolute priority not working
Markus commented on JENKINS-24618 Absolute priority not working Hi Pedro, I am not the expert on this plugin. But for us, some jobs are in multiple views. It seems that the Job Priorities (advanced-build-queue) starts at the top and when a job matches a criteria, it gets that priority. It does not matter if the jobs is in other views further down in the list. We use regular expressions for the views, but some priorities are set using the Job Priorities criteria. Such as manually started jobs. We don't have any priorities set up for individual jobs, those are all removed. I do not know if that is required. We have also disabled "allow priorities directly on Jobs". I do not know if that is required. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24962) Cannot assign a JobGroup to a Nested (sub) View
Markus updated JENKINS-24962 Cannot assign a JobGroup to a Nested (sub) View Change By: Markus (02/Oct/14 8:54 AM) Summary: CannotassignaJobGrouptoaNested (sub) View This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24962) Cannot assign a JobGroup to a Nested View
Markus created JENKINS-24962 Cannot assign a JobGroup to a Nested View Issue Type: Bug Assignee: Magnus Sandberg Components: prioritysorter Created: 02/Oct/14 8:53 AM Description: When sub views are created using the Nested Views Plugins, these sub views cannot be selected when assigning Job Priorities to JobGroups. To reproduce: Install Priority Sorter and the Nested View Plugin Create a new View and choose the "Nested View" type Create a couple of sub views in this Nested View Go to http://jenkins:8080/advanced-build-queue/ and Add a Job Group What is expected All normal Views and all Nested Views and all views in the Nested Views are listed Actual outcome Only the normal Views and the Nested Views are show. The sub views are not shown Environment: Jenkins 1.554.1 Priority Sorter Plugin 2.8 Nested View Plugin 1.14 Project: Jenkins Priority: Major Reporter: Markus This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24618) Absolute priority not working
Markus commented on JENKINS-24618 Absolute priority not working I had global priorities set up in http://jenkins:8080/advanced-build-queue/. These priorities overrules the job specific priorities. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24618) Absolute priority not working
Markus edited a comment on JENKINS-24618 Absolute priority not working Comment edited. Priority works for me, I had a configuration problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24618) Absolute priority not working
Markus edited a comment on JENKINS-24618 Absolute priority not working Previous comment removed. Priority works for me, I had a configuration problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [tasks-plugin] (JENKINS-24708) Message is missing from REST API
Markus commented on JENKINS-24708 Message is missing from REST API Thank you! There is some delay before plugins are released to us and we don't update continuously. But I'll fetch it as soon as possible and close when verified. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [cli] (JENKINS-12302) Remote call on CLI channel from [ip] failed
Markus Hjerto closed JENKINS-12302 as Fixed Remote call on CLI channel from [ip] failed Change By: Markus Hjerto (08/Apr/13 11:56 AM) Status: Resolved Closed 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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto commented on JENKINS-16861 Add support for the Claim Plugin You're right. You cannot customize support for every plugin for everyone. I don't fully understand how your planned features will be, but I understand the basic ideas and I think they will meet my needs. 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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto
commented on JENKINS-16861
Add support for the Claim Plugin
Thank you again. After a lot of trial and errors, the UserProperty problem was resolved: The class exists on the Jenkins production server, not on my simple test server. I guess it is because my test server only has the AD plugin installed but it does not use it. It uses Jenkins's own user database. Also, then "last line" trick did the trick.
But I've realized, now that this works, that I have to do this as a pre-mail script. I'd like to replace the default recipients and I'd like it not to email the Culprits and Committers if the job is claimed. So I have to edit the complete recipients list just before the mail is sent, which is a pre-send script. I'll guess I'll have to do some scripting to distribute the pre-send script to all the jobs until we can add global pre-mail scripts (JENKINS-14508).
Here's what I ended up with, for future googlers. I kept the array in case I'd like to add more recipients from other sources later.
def committers = []
build.actions.each { action -
if(action.class.name == "hudson.plugins.claim.ClaimBuildAction" action.isClaimed()) {
hudson.model.User user = hudson.model.User.get(action.getClaimedBy());
address = user.getProperty(hudson.tasks.Mailer.UserProperty.class).address
committers[0]=address
}
}
// here comes the last line, it MUST be the last line for this to work!!
committers.unique().join(',')
I'd still like a built-in support for the Claim plugin, which was the initial request, so I'd prefer to leave this as open. But I'll accept a Won't Fix if you prefer that such things are resolved using the (excellent) scripting features.
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] (JENKINS-14508) Default pre-send script in Jenkins Configuration
Markus Hjerto
commented on JENKINS-14508
Default pre-send script in Jenkins Configuration
That is how at least I'd like it. All the other fields have a global config level DEFAULT option, but the pre-sim script does not. Adding ${DEFAULT_PRE-SEND_SCRIPT} in the pre-sim script field in a job (it should maybe be there by default), should execute a pre-sim script defined globally. It would make it much easier to run the same script on all the jobs.
An alternative could be to adds support for ${SCRIPT, script="my-default-script.groovy"}, which is fetched from the email-templates directory.
Or even better - both. Let the pre-sim script behave like all the other fields.
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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto
commented on JENKINS-16861
Add support for the Claim Plugin
Thank you very much Alex. Your pointers, combined with Chris's implementation in JENKINS-12421, did the trick. I now have a way to solve this, but I was only able to make it run when I did it as a pre-send script, which means that the script must be duplicated in every job (hundreds).
So, you say it is possible to run this script directly from the Project Recipient List? I've added ${SCRIPT, script="get-claim-recipient.groovy"} to a job's Default Content (for debugging) and it seems to run. But I'm not able to output any text from the script. It does not accept %sometext% (unexpected token: ). I've also tried println("Hello"); but nothing is written in the email. logger.println() also does not work (No such property: logger for class).
Also, I'm not able to make mailext/groovy accept "address = user.getProperty(hudson.tasks.Mailer.UserProperty).getAddress();". (No such property: hudson for class). This line works well if it is a pre-send script. I've tried to import hudson.model.User.* as well.
And finally, if I do it like this, then will I be able to provide any default recipients (for non-claimed jobs) in the job configuration? Maybe I should simply wait for JENKINS-14508.
I obviously don't have enough knowledge here, so I apologize for all my novice questions and humbly hope for some more guidelines.
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] (JENKINS-12421) Add pre-send step to email-ext that can modify the mail message object
Markus Hjerto commented on JENKINS-12421 Add pre-send step to email-ext that can modify the mail message object Thank you very much, Chris. Your script works perfectly! 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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto
commented on JENKINS-16861
Add support for the Claim Plugin
You are right. I should be able to create a script for that, which changes the recipient list based on the claim status.
I've never done any groovy scripts before, but at least I've been able to get the claim status. But after hours of searching, I've not been able to get the users e-mail address from the Jenkins user database. For now, I'll use the returned username as email address (usern...@domain.com), unless you could point me in the right directions? I'm looking for something like hudson.users.getEmailAddress(claim.getClaimedBy()).
For future searchers, this is what I've got so far. It is not production ready - It must be modified to set the email address before it can be used. I'll see if I can attach the finished script when (or if) I'm able to finish it.
def claim = it.getAction("hudson.plugins.claim.ClaimBuildAction")
if (claim != null) {
if (claim.isClaimed() == true) {
%Claimed by: ${claim.getClaimedBy()} (${claim.getClaimedByName()})\n%
if (claim.hasReason() == true ) {
%Reason: ${claim.getReason()}\n%
}
if (claim.hasClaimDate() == true ){
%Claimed at: ${claim.getClaimDate()}\n%
}
} else {
%Not claimed\n%
}
} else {
%Claim not supported for this job\n%
}
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] (JENKINS-12421) Add pre-send step to email-ext that can modify the mail message object
Markus Hjerto commented on JENKINS-12421 Add pre-send step to email-ext that can modify the mail message object terryl westerhold, I'm trying to achieve the same goal (JENKINS-16861) but I'm struggling with the script. Do you have something you could share? 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] (JENKINS-16855) Add Allow broken build claiming function
Markus Hjerto created JENKINS-16855 Add Allow broken build claiming function Issue Type: New Feature Assignee: mdonohue Components: configurationslicing Created: 18/Feb/13 10:02 AM Description: It would be great if it was possible to add "Allow broken build claiming". See the https://wiki.jenkins-ci.org/display/JENKINS/Claim+plugin plugin. The plugin has 1800 installations, so I'd assume others would need it as well. (Thanks for a great plugin!) Project: Jenkins Priority: Major Reporter: Markus Hjerto 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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto
created JENKINS-16861
Add support for the Claim Plugin
Issue Type:
New Feature
Assignee:
Alex Earl
Components:
email-ext
Created:
18/Feb/13 2:14 PM
Description:
It would be great if this plugin could add support for the Claim Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Claim+plugin, 1800 installations).
I imagine two additional features shown to the user in the Project configuration, if the Claim Plugin is installed:
A "recipient group" called "Claimer" or something so that we can select when this person gets an email.
One or more triggers related to a failed build which is already claimed. Maybe it could be a checkbox to the existing triggers ("...and is already claimed")
The end result would be that the user can configure that for example only the owners and the claimer (i.e. not the other culprits) will be emailed when a build with a sticky Claim fails again.
Project:
Jenkins
Priority:
Major
Reporter:
Markus Hjerto
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] (JENKINS-16861) Add support for the Claim Plugin
Markus Hjerto commented on JENKINS-16861 Add support for the Claim Plugin I don't think the Claim Plugin exports any variables, but I don't know. I've seen the claim status in the builds' APIs. What I'm looking for is a possibility to make Jenkins not send "build is still failing" e-mails to all committers if a user has Claimed the failing build. Only the claimer (and maybe the default recipients) should get e-mails if the build is claimed. But if no-one has claimed the failing build, then all committers should get emails as normal. Therefore I don't think it would help to add a variable to the recipient list, if such a variable is exported by the Claim Plugin. I was also considering the custom script that can execute before e-mailing. But this can only stop all e-mails (cancel=true), not modify the recipients list (I think?). I would like it to send e-mails to different recipients depending on the claim status. The end result and goal is less spam. I think this would fit nicely in email-ext, since I can select who'll get emails when (1st fail, next fails etc). It only needs a "if claimed" option to the triggers and the ability to fetch the claimer's username from the job's API. 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] (JENKINS-16801) Claim Report don't list all jobs when Default View is set in Jenkins
Markus Hjerto commented on JENKINS-16801 Claim Report dont list all jobs when Default View is set in Jenkins I agree. And your proposed solution is acceptable. (Although "acceptable" and "not acceptable" is a bit strong for a plugin I/we use for free...) There is already a view called "All" so I can simply select that view and then the plugin works as I expected. I've noticed that the "Wall Display" plugin uses another approach: It uses the view you have active when you click "Wall Display" in the menu to the left. Although I did not find that approach very intuitive at first, it could be that this is the recommended approach in the Jenkins 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] (JENKINS-16576) Display Possible Culprits
Markus Hjerto updated JENKINS-16576 Display Possible Culprits Change By: Markus Hjerto (14/Feb/13 9:30 AM) Description: TheabandonedpluginRadiatorViewPluginwasabletoshowPossibleCulpritsforjobsthatwerefailing ,aswellasindicatethatafailingjobhadbeenclaimed(viatheClaimPlugin) .ItwouldbegreatifWallDisplaycoulddisplaypossibleculprits andclaims . 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] (JENKINS-16799) Show that a failing build has been claimed
Markus Hjerto created JENKINS-16799 Show that a failing build has been claimed Issue Type: Improvement Assignee: Unassigned Components: jenkinswalldisplay Created: 14/Feb/13 9:29 AM Description: The abandoned plugin Radiator View Plugin was able to indicate that a failing job had been claimed (via the Claim Plugin). It would be great if Wall Display could claims. The Claim Plugin has 1800 installations, so I'd assume that more people would like this. Project: Jenkins Priority: Major Reporter: Markus Hjerto 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] (JENKINS-16799) Show that a failing build has been claimed
Markus Hjerto closed JENKINS-16799 as Cannot Reproduce Show that a failing build has been claimed My bad - it seems that it does support it. Claimed jobs have yellow borders. Change By: Markus Hjerto (14/Feb/13 9:35 AM) Status: Open Closed Resolution: CannotReproduce 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] (JENKINS-16801) Claim Report don't list all jobs when Default View is set in Jenkins
Markus Hjerto created JENKINS-16801 Claim Report dont list all jobs when Default View is set in Jenkins Issue Type: Bug Assignee: Christian Åkerström Components: claim Created: 14/Feb/13 10:03 AM Description: Problem: Setting a "Default view" in Jenkins excludes all jobs not in this default view from the claim report. Steps to reproduce: 1. Add a new view MyNewView in Jenkins. Include only some of the claimed failing jobs 2. Go to http://jenkins:8080/configure 3. Set your new view (MyNewView) as "Default view". Save. 4. View the claim report (http://jenkins:8080/claims/). Only the claimed and failing jobs in MyNewView are listed, although the Claim Report should show all claimed and failing jobs. Environment: Jenkins Claim Plugin version 2.1 Jenkins ver. 1.480.2 (LTS) CentOS release 5.9 Project: Jenkins Priority: Critical Reporter: Markus Hjerto 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] (JENKINS-16576) Display Possible Culprits
Markus Hjerto closed JENKINS-16576 as Not A Defect Display Possible Culprits I had an old version. This feature is already there. Sorry. Change By: Markus Hjerto (14/Feb/13 10:08 AM) Status: Open Closed 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 -- 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] (JENKINS-16576) Display Possible Culprits
Markus Hjerto created JENKINS-16576 Display Possible Culprits Issue Type: Improvement Assignee: Unassigned Components: jenkinswalldisplay Created: 31/Jan/13 5:01 PM Description: The abandoned plugin Radiator View Plugin was able to show "Possible Culprits" for jobs that were failing, as well as indicate that a failing job had been claimed (via the Claim Plugin). It would be great if Wall Display could display possible culprits and claims. Project: Jenkins Priority: Major Reporter: Markus Hjerto 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] (JENKINS-16320) Mouse-over in plot should show series name
Markus Hjerto created JENKINS-16320 Mouse-over in plot should show series name Issue Type: Improvement Assignee: nidaley Components: plot Created: 11/Jan/13 3:55 PM Description: When hovering the mouse over a value in the plot, the build number and date is shown, as well as the exact value. It would be an improvement if this text could include the series name. This is useful for plots with many series where the plugin starts to re-use colors. Project: Jenkins Priority: Major Reporter: Markus Hjerto 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-16305) Add support for Quiet period configuration slicing
Markus Hjerto created JENKINS-16305 Add support for Quiet period configuration slicing Issue Type: New Feature Assignee: mdonohue Components: configurationslicing Created: 10/Jan/13 4:18 PM Description: It would be great if thus plugin could support slicing the Quiet period configuration item. Thanks for a great plugin! Use it all the time! Project: Jenkins Priority: Major Reporter: Markus Hjerto 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-15912) Shell script files output is not displayed
Markus Hjerto
created JENKINS-15912
Shell script files output is not displayed
Issue Type:
Bug
Assignee:
Gregory Boissinot
Components:
postbuildscript
Created:
23/Nov/12 1:49 PM
Description:
When configuring a Post-build Action to execute a shell script ("Batch or a shell script files to execute"), the output from the script is not displayed. If the script is added as a Build step (still Post-build Action), the output is displayed.
If this is intended behavior, maybe the "Batch or a shell script files to execute" option should have a check box "Display output from script"?
Environment:
Jenkins ver. 1.480.1
Linux/Cent OS
Jenkins Post-Build Script Plug-in: 0.10
Project:
Jenkins
Priority:
Major
Reporter:
Markus Hjerto
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-2550) Email should be sent when build node is taken offline.
Markus Hjerto commented on JENKINS-2550 Email should be sent when build node is taken offline. I've now created my own Groovy script that does this. It is based on this script from the Jenkins wiki, but I don't let it restart nodes automatically. I assume there's a reason why the node online so I'd like to look at it first. I think it's a great template for other states/parameters that we need to monitor. For example I've added a small check to ensure that the nodes are in sync since we recently had that problem when switching to winter time. Also, my version does not send e-mails if the node is "Disconnected by ..." since I assume that there's a reason why someone disconnected the node manually. My modifications are so small that there's no point posting the script here. If you want the same solution/workaround, check out the link above and adopt to your needs. It was very easy to expand even without much Groovy knowledge 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-11638) When claimed, stop sending e-mails to individuals who broke the build
Markus Hjerto commented on JENKINS-11638 When claimed, stop sending e-mails to individuals who broke the build There is no interest in this feature? It would certainly reduce the noise in big projects. As of now, no claim information is included in any build failed-emails. As a minimum, it would even help if the emails said "Already claimed build failed in Jenkins" or something. 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-13790) Subversion externals fail
Markus Hjerto
commented on JENKINS-13790
Subversion externals fail
No we don't need subversion 1.7. We upgraded because of a another problem ("org.tmatesoft.svn.core.SVNException: svn: REPORT /seesaw/!svn/vcc/default failed", "Checksum mismatch while updating '/jenkins-directory/products/run/.svn/text-base/RUN_ALL.svn-base'; expected: '6d28a7249c635f15621f5f5ac5fa28d2', actual: 'null'")
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-13790) Subversion externals fail
Markus Hjerto commented on JENKINS-13790 Subversion externals fail Stephan, We downgraded to 1.39 and it seems to have "solved" the problem. YMMV. 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-13790) Subversion externals fail
Markus Hjerto commented on JENKINS-13790 Subversion externals fail We are seeing the same issue after updating to 1.40. The job fails. This is the output: AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class At revision 5215 AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class FATAL: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:646) at hudson.FilePath.act(FilePath.java:821) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) 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:239) Caused by: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:702) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.StreamCorruptedException: invalid type code: 41 at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) 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-13429) Nested views not showing up with just read perms for View
[ https://issues.jenkins-ci.org/browse/JENKINS-13429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161761#comment-161761 ] Markus Hjerto commented on JENKINS-13429: - Seeing the same with matrix based security. Jenkins 1.460 Nested View Plugin 1.8. Active Directory plugin 1.23 Nested views not showing up with just read perms for View - Key: JENKINS-13429 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429 Project: Jenkins Issue Type: Bug Components: nested-view Affects Versions: current Reporter: M S Assignee: Kohsuke Kawaguchi Labels: jenkins, plugin, views Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 1.1.2 User has read permissions for View but Jenkins main page is missing Nested views (even if they have sub views with jobs). Adding configure perms for View results in Nested views showing up correctly. It looks like it's connected with: Added the View.READ permission to control visibility of views, and updated the default implementation to hide empty views. (issue 3681) -- 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-13340) Compiler Warnings menu item gone when no compiler warnings
Markus Hjerto created JENKINS-13340: --- Summary: Compiler Warnings menu item gone when no compiler warnings Key: JENKINS-13340 URL: https://issues.jenkins-ci.org/browse/JENKINS-13340 Project: Jenkins Issue Type: Bug Components: warnings Affects Versions: current Environment: compiler warnings version 3.28 jenkins version 1.458 Reporter: Markus Hjerto Assignee: Ulli Hafner Priority: Minor When we've finally been able to remove all the compiler warnings in a project, then the compiler warnings menu item in the left menu column disappear. It is also not present in the new hover menus introduced in Jenkins not that long ago. I can access it from clicking on the build. -- 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-13340) Compiler Warnings menu item gone when no compiler warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161215#comment-161215 ] Markus Hjerto commented on JENKINS-13340: - I would expect a list as normal where the Fixed warnings field contains the number of warnings that was fixed. I could click that number and get more information about the warnings. This is still relevant even if we have no warnings anymore. Today I can access that page by simply adding /warningsResult to the URL, even if the menu is not there. I think the main problem is that it confused me that the menu was gone. I was afraid that the warning had stopped working or something. In the end this is probably a preference decision, so I'll leave it up to you to decide. You may know much more about a user-friendly UIs than I do. Great plugin, by the way! Compiler Warnings menu item gone when no compiler warnings -- Key: JENKINS-13340 URL: https://issues.jenkins-ci.org/browse/JENKINS-13340 Project: Jenkins Issue Type: Bug Components: warnings Affects Versions: current Environment: compiler warnings version 3.28 jenkins version 1.458 Reporter: Markus Hjerto Assignee: Ulli Hafner Priority: Minor When we've finally been able to remove all the compiler warnings in a project, then the compiler warnings menu item in the left menu column disappear. It is also not present in the new hover menus introduced in Jenkins not that long ago. I can access it from clicking on the build. -- 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-13058) E-mail to individuals who broke the build is sent to wrong address
Markus Hjerto created JENKINS-13058:
---
Summary: E-mail to individuals who broke the build is sent to
wrong address
Key: JENKINS-13058
URL: https://issues.jenkins-ci.org/browse/JENKINS-13058
Project: Jenkins
Issue Type: Bug
Components: active-directory, mail, subversion
Affects Versions: current
Environment: CentOS release 5.8
jenkins v1.455
subversion v1.39
active-directory v1.23
Reporter: Markus Hjerto
Priority: Critical
First of all - this problem occurred, from what I can see in my mail archive,
around March 1st. It could be related to the 1.452 Jenkins update.
When a build fails the emails sent to individuals who broke the build is sent
to the wrong address. The e-mails are sent to
*domainname_usern...@domainname.com* instead of *usern...@domainname.com* or
even better full.email.addr...@domainname.com
I see the following in the logs when a build fails:
{noformat}
WARNING: Credential exception tying to authenticate against DomainName.com
domain
org.acegisecurity.BadCredentialsException: Authentication was successful but
cannot locate the user information for DomainName_UserName
{noformat}
So it seems that the active directory plugin is looking for the wrong username.
It should look up UserName, not DomainName_UserName . When I log in to
Jenkins, I can see in the logs that it looks up UserName in AD, which is
correct. I can also see that it is provided with all email addresses, full name
etc. So I guess the AD plugin is working.
I believe the problem is related to the DomainName\UserName format that
Windows/Active Directory is using. Our SVN server is also using AD. When I do a
svn info on any resource, the LastChanged Author is DomainName\UserName.
Could it be that the SVN plugin is sanitizing DomainName\UserName to
DomainName_UserName?
--
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-10771) hudson.util.IOException2: remote file operation failed
[
https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159272#comment-159272
]
Markus Hjerto commented on JENKINS-10771:
-
Usually it helps to disconnect and reconnect the slave here, but it did not
work this time. I had to restart the entire service. Running Jenkins 1.451 on
CentOS 5.7.
{code}
hudson.util.IOException2: remote file operation failed:
/tmp/jenkins-workspace/Checkout at hudson.remoting.Channel@377e66a9:svnworker
at hudson.FilePath.act(FilePath.java:784)
at hudson.FilePath.act(FilePath.java:770)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:742)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
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:1409)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.io.InterruptedIOException
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:775)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:752)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2099)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(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: java.lang.InterruptedException
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:87)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:120)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:787)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:768)
... 11 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: OPTIONS
/seesaw/projects/nrf4368/digital/nRF31512/atpg/trunk failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:294)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1011)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:876)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:901)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
... 17 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to
try. Authentication failed
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:219)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:584)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
... 28 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: No credential to try.
