date:20140515

ikedam
commented on JENKINS-23012

Build-timeout plugin causes builds to slow

I agree that it's risky to install testing versions to the production environmtnt. I'm not so sure what the root cause is and how to fix that.
I'll try to reproduce it in my local enviroment.

Please let me know followings:

OS of the master node and slave nodes.
Outline of your build process. For example, running maven, running gcc, or running other native process.

I think whether builds are performed in Java or native processes can affect this problem.

How much log outputs? I think the size of whole log and the time builds take will be helpful.

I think much log outputs may trigger the problem.

Can you see what process gets slow in builds?

If building processes outputs timestamps, please compare them before and after downgrading build-timeout plugin.
If you installed Timestampler plugin, please compare timestamps in console outputs.

Timestamps logged with timestampler-plugin may differ from the activity of the building process as they can be buffered and delayed.

If you don't have timestamper-plugin installed, you'd better not install that as that plugin also captures log output and may cause the same problem.

I think there are following possible causes to slow builds:

Native processes lauched in builds get slow.

Like processes launched with "Execute shell".
I don't think Jenkins cannot affect native processes as they should be completely separated by OS.
But slowed log output can flood output buffers of processes and may cause the processes hold for a while.

Jenkins takes much time to proceed build steps.

In this case, native processes don't get slow.

Jenkins takes much time to start and stop builds.

This can be caused by synchronized.

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] [gerrit] (JENKINS-23059) Gerrit Repo plugin does not support variable expansion

2014-05-15 Thread fzbass...@yahoo.com (JIRA)















































Eric Wallengren
 created  JENKINS-23059


Gerrit Repo plugin does not support variable expansion















Issue Type:


Bug



Affects Versions:


current



Assignee:


Unassigned


Components:


gerrit



Created:


16/May/14 12:37 AM



Description:


The SCM plugins I have used in the past have had the ability to support variable expansion:

On a master I can define say VERSION:

VERSION=1.2.2

I can pass it as a parameter to a slave job using SVN for use in a branch specification:

http://svn.corp/project/branches/${VERSION}

The only place it's maintained is on the master (good when I'm running half a dozen architecture specific slaves).

The Gerrit Repo plugin has the ability to use a URL as a manifest (instead of a fixed manifest in the 'Local Manifest' field).  Unfortunately I'm unable to pass a URL as a variable:

Master:
JOBNAME=mybuild
JOBNUM=12

Slave (in 'Local Manifest'):

http://server/${JOBNAME}/${JOBNUM}/default.xml

It does not expand, neither do any of the other fields... Bummer!





Environment:


Linux/Ubuntu




Project:


Jenkins



Labels:


plugin
slave
git
scm




Priority:


Major



Reporter:


Eric Wallengren

























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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow

2014-05-15 Thread darrel...@gmail.com (JIRA)















































Darrel Vuncannon
 commented on  JENKINS-23012


Build-timeout plugin causes builds to slow















No, I cannot subject my employer's production jenkins to this problem again because that would impact hundreds of developers.  That's unfortunate, because I know you need a place to investigate this problem.  

Can you think of another way to proceed?  If you think you know the problem and can generate a version that you think is 70% likely to fix this problem, then I will risk my jenkins instance on trying 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/d/optout.

[JIRA] [subversion] (JENKINS-8312) svn:externals not being checked out















































Daniel Beck
 commented on  JENKINS-8312


svn:externals not being checked out















zeliff: Likely related to JENKINS-21785 as of Subversion plugin 2.x. Try specifying Additional Credentials as described there. Also, note that externals are generally rather broken before 2.3.

Given the massive changes to SVN auth in 2.0, I'm inclined to close this unless it is confirmed to still occur in 2.x. Does anyone object?



























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] [ghprb] (JENKINS-22253) Problems Parsing

2014-05-15 Thread pe...@algarvio.me (JIRA)















































Pedro Algarvio
 commented on  JENKINS-22253


Problems Parsing















that job's config https://gist.github.com/s0undt3ch/523064c5c2c04ac50ab0



























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] [core] (JENKINS-22936) Move rename infrastructure from Job to AbstractItem















































Daniel Beck
 commented on  JENKINS-22936


Move rename infrastructure from Job to AbstractItem















Also, rename is not the same as Delete + Create. That needs to go (Job.doDoRename).



























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] [groovy-postbuild] (JENKINS-21480) Groovy postbuild add ability to use external groovy script
















































Daniel Beck
 resolved  JENKINS-21480 as Not A Defect


Groovy postbuild add ability to use external groovy script
















Martin's comment has shown that this is in fact possible, therefore closing as not a defect.

The inability to use variables in the additional classpath field is already tracked in JENKINS-15210.





Change By:


Daniel Beck
(15/May/14 10:19 PM)




Status:


Open
Resolved





Resolution:


Not A Defect



























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] [ghprb] (JENKINS-22253) Problems Parsing

2014-05-15 Thread pe...@algarvio.me (JIRA)















































Pedro Algarvio
 commented on  JENKINS-22253


Problems Parsing















We do not have the multiple scm plugin installed.

We are however using the multijob plugin.

The multijob plugin is the one that receives the pull request information. It then feeds that PR data down to descending jobs.

What additional information can I provide?



























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] [perforce] (JENKINS-23058) Perforce plugin tickets failing

2014-05-15 Thread cmay...@cisco.com (JIRA)
















































Caleb Mayeux
 resolved  JENKINS-23058 as Not A Defect


Perforce plugin tickets failing
















Please ignore this bug. Fail on my side.

Misleading output obscured a problem in our environment.





Change By:


Caleb Mayeux
(15/May/14 9:44 PM)




Status:


Open
Resolved





Resolution:


Not A Defect



























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] [perforce] (JENKINS-23058) Perforce plugin tickets failing

2014-05-15 Thread cmay...@cisco.com (JIRA)
















































Caleb Mayeux
 closed  JENKINS-23058 as Not A Defect


Perforce plugin tickets failing
















Change By:


Caleb Mayeux
(15/May/14 9:44 PM)




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/d/optout.

[JIRA] [perforce] (JENKINS-23058) Perforce plugin tickets failing

2014-05-15 Thread rob.pe...@gmail.com (JIRA)















































Rob Petti
 commented on  JENKINS-23058


Perforce plugin tickets failing















You've verified your password? But I thought you said passwords were not accepted on your server?

Keep in mind that often tickets are bound to specific hosts. If you are supplying your ticket as your password, it will reject the connection if the build isn't running on the host the ticket was created for.



























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] [perforce] (JENKINS-23058) Perforce plugin tickets failing

2014-05-15 Thread rob.pe...@gmail.com (JIRA)
















































Rob Petti
 assigned  JENKINS-23058 to Unassigned



Perforce plugin tickets failing
















Change By:


Rob Petti
(15/May/14 9:09 PM)




Assignee:


Rob Petti



























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] (JENKINS-8312) svn:externals not being checked out

2014-05-15 Thread zel...@java.net (JIRA)















































zeliff
 commented on  JENKINS-8312


svn:externals not being checked out















Problem still exists in Jenkins 1.563, Subversion plugin 2.2.  The workarounds described by Henry Chan and Jack Ace do not 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/d/optout.

[JIRA] [perforce] (JENKINS-23058) Perforce plugin tickets failing

2014-05-15 Thread cmay...@cisco.com (JIRA)

Caleb Mayeux
created JENKINS-23058

Perforce plugin tickets failing

Issue Type:

Bug

Assignee:

Rob Petti

Components:

perforce

Created:

15/May/14 8:19 PM

Description:

If your perforce server is more secure, it only accepts ticket based authentication. Unfortunately, the Jenkins perforce plugin appears to have issues in this regard. Judging from the output, the commands generated are correct, but there is something that is amiss.

Build output snippet:
[test] $ /auto/perforce/p4bin/p4 login -a -p
[test] $ /auto/perforce/p4bin/p4 -P 618EBB180 workspace -o cmayeux:condor-main-js-ut-exp3-912254826

Running these exact commands on the slave outside of Jenkins yields the desired result. However, in the plugin, I get the following output:

Caught exception communicating with perforce. Perforce password (P4PASSWD) invalid or unset.com.tek42.perforce.PerforceException: Perforce password (P4PASSWD) invalid or unset.
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:406)
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:301)
at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61)
at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1615)
...

Not sure what exactly is going wrong. I've verified my password six ways to Sunday. Note this only occurs when perforce is secured so as to not allow environment variables or .p4configs be used for the P4PASSWD.

Environment:

Jenkins 1.554.1, perforce plugin 1.3.27, RHEL 5.5

Project:

Jenkins

Priority:

Major

Reporter:

Caleb Mayeux

[JIRA] [email-ext] (JENKINS-21180) "Attach Build Log" conflicts with the ansi-color plugin

2014-05-15 Thread slide.o....@gmail.com (JIRA)















































Alex Earl
 commented on  JENKINS-21180


"Attach Build Log" conflicts with the ansi-color plugin















It will be part of 2.38, which I hope to release this week.



























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] [performance-plugin] (JENKINS-23057) Ability to automatically filter outliers from trend data

2014-05-15 Thread sog...@gmail.com (JIRA)















































Sargon Benjamin
 created  JENKINS-23057


Ability to automatically filter outliers from trend data















Issue Type:


New Feature



Assignee:


Manuel Carrasco



Components:


performance-plugin



Created:


15/May/14 6:55 PM



Description:


The plugin is really great!

One downside is that the trend graphs get totally skewed and become no longer usable when an outlier or two exist.  

It would be nice to have an option that we can select to automatically filter outliers from the trend graphs so that the trend graphs can be scaled more reasonably.




Project:


Jenkins



Priority:


Major



Reporter:


Sargon Benjamin

























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] [email-ext] (JENKINS-21180) "Attach Build Log" conflicts with the ansi-color plugin

2014-05-15 Thread ja...@jacobweber.com (JIRA)















































Jacob Weber
 commented on  JENKINS-21180


"Attach Build Log" conflicts with the ansi-color plugin















Meant to say: I'm seeing the ANSI escape sequences in my emails.



























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] [email-ext] (JENKINS-21180) "Attach Build Log" conflicts with the ansi-color plugin

2014-05-15 Thread ja...@jacobweber.com (JIRA)















































Jacob Weber
 commented on  JENKINS-21180


"Attach Build Log" conflicts with the ansi-color plugin















Has this change been released? I'm using the ANSI escape sequences in my emails. I'm using the ${BUILD_LOG} token in the email body, and it contains things like  [0;31m.



























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] [core] (JENKINS-23056) Jenkins UI hangs after a day or two on a large installation

2014-05-15 Thread aba...@java.net (JIRA)















































abayer
 commented on  JENKINS-23056


Jenkins UI hangs after a day or two on a large installation















Ah-ha! I'll see if I can figure out who's doing that, 'cos I'm willing to bet that there are builds depending on being able to download from workspaces...



























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] [git-parameter] (JENKINS-22886) Does not fetch/list current/new tags
















































ngiger
 assigned  JENKINS-22886 to ngiger



Does not fetch/list current/new tags
















Change By:


ngiger
(15/May/14 6:38 PM)




Assignee:


Niklaus Giger
ngiger



























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] [git-parameter] (JENKINS-23051) Support regular expression when filtering tags
















































ngiger
 assigned  JENKINS-23051 to ngiger



Support regular _expression_ when filtering tags
















Change By:


ngiger
(15/May/14 6:38 PM)




Assignee:


Niklaus Giger
ngiger



























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] [core] (JENKINS-23056) Jenkins UI hangs after a day or two on a large installation

2014-05-15 Thread jgl...@cloudbees.com (JIRA)















































Jesse Glick
 commented on  JENKINS-23056


Jenkins UI hangs after a day or two on a large installation















Somebody is downloading lots of files from workspaces on slow slave nodes. Try blocking workspace read access to everyone.



























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] [extended-choice-parameter] (JENKINS-19907) Cannot use multiple parameters with parameter type equal to Radio Buttons

2014-05-15 Thread lrobertso...@hotmail.com (JIRA)















































Luke Robertson
 commented on  JENKINS-19907


Cannot use multiple parameters with parameter type equal to Radio Buttons















This is due to the fields all have the name="value" but can be fixed following the Structured Form Submission guidelines (https://wiki.jenkins-ci.org/display/Jenkins/structured+form+submission) where the the name can be appended with a string which is removed during submission. 

Please see pull request: 

http://github.com/jenkinsci/extended-choice-parameter-plugin/pull/6



























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] [core] (JENKINS-23056) Jenkins UI hangs after a day or two on a large installation

2014-05-15 Thread aba...@java.net (JIRA)















































abayer
 created  JENKINS-23056


Jenkins UI hangs after a day or two on a large installation















Issue Type:


Bug



Assignee:


Unassigned


Attachments:


hung_jenkins_stack_120514, hung_jenkins_stack_150514



Components:


core



Created:


15/May/14 6:33 PM



Description:


For the last while, the Jenkins instance at builds.apache.org has been hanging every couple days (or more frequently). We've had problems with hanging slaves, which typically seem to be somehow connected with Maven jobs (https://gist.github.com/abayer/cc951f6b7f5f670232ab for the threaddump there, ubuntu6 was hanging at that point, if I remember correctly - threaddump from a hung slave at https://gist.github.com/abayer/d7c3e87f5c0ae90927c9) but the really nasty issue is the UI hanging.

Jobs still seem to be running (I think - not 100% sure on that front), but the UI locks up and we get 502s from httpd in front of Tomcat. I've attached the stack dumps for two of these hangs. If there's anything else you need from us at Apache, let me know and I can arrange it - this is a fairly critical problem for us. My gut instinct is that it's something to do with the slave lockup, which itself seems to be something to do with Maven jobs (of which we have over 600 with an average of nearly 40 modules per job, so...yeah, lots and lots of MavenModules floating around, which may be, in tandem with JENKINS-19392, the reason we have 20 minute startup times), but I could very well be wrong about all of it.




Environment:


1.564-SNAPSHOT, Tomcat 7, Ubuntu 12.04.4




Project:


Jenkins



Priority:


Critical



Reporter:


abayer

























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] (JENKINS-21850) The Claim report should not include disabled projects

2014-05-15 Thread ewatk...@gmail.com (JIRA)















































Eric Balin-Watkins
 commented on  JENKINS-21850


The Claim report should not include disabled projects















In addition, I think aborted builds should only be reported when the most recent non-aborted build was a failure.  If all builds for a job have been aborted, or the most recent non-aborted build succeeded, then don't show the failure.

But that should maybe be filed as a separate issue.



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

Daniel Beck
commented on JENKINS-21785

Check for changes in folders linked via svn:externals fails due to missing credentials

A valid enhancement request would be to give a checkbox (default to off) to use matching module credentials when doing a checkout of externals. That would at least make things easier for the 80% who don't need the gaping security hole fixed because of their permissive SVN server security model.

Not sure how that would work. In checkout, it's already effectively this way, and for polling etc. you have no idea which module introduced which external (AFAIK – is there a field I am missing?).

Alternative approach:

The current implementation allows to leave the per-module credentials empty and only specify Additional Credentials (just ignore the scary form validation errors) which are then used for all locations.

We could go one step further and add a 'Default Credentials' field (or reinterpret an Additional Credential with empty realm?). Leave that field empty/don't define such an Additional Credential, and you get the current behavior. Select a credential as Default Credential/define such an Additional Credential and you can skip configuring any others.

This way, users conscious about the security issue prevented by the credentials implementation can continue to specify individual credentials and curse SVNKit for its behavior while the rest can configure one credential, and don't have to care about externals or realms.

WDYT?

[JIRA] [build-pipeline] (JENKINS-19121) Build pipeline plugin no longer prompts for parameters of parameterised job

2014-05-15 Thread elma...@gmail.com (JIRA)















































Matias Fernandez
 commented on  JENKINS-19121


Build pipeline plugin no longer prompts for parameters of parameterised job















Can confirm this is an issue with Jenkins 1.552 and build-pipeline-plugin 1.4.2.



























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] (JENKINS-23042) Claim report shows a max of 50 failures

2014-05-15 Thread ewatk...@gmail.com (JIRA)















































Eric Balin-Watkins
 commented on  JENKINS-23042


Claim report shows a max of 50 failures















Here's the reason:

resources/hudson/plugins/claim/ClaimedBuildsReport/buildListTable.jelly:




I'm going to make it 500 for now, which is around the number of total jobs we have on our jenkins deployment.  

If someone else wants to make a real fix, that would be great.  Ideally, we should be able to filter dynamically based on the name of the jobs.  Otherwise, making the list page-able, or having a gradual expansion of the list sounds fine.



























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] [scm-sync-configuration] (JENKINS-23036) Context Path Missing from Reload link

2014-05-15 Thread kiana.tenny...@gmail.com (JIRA)
















































kiana tennyson
 resolved  JENKINS-23036 as Fixed


Context Path Missing from Reload link
















Change By:


kiana tennyson
(15/May/14 5:20 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/d/optout.

[JIRA] [master-slave] (JENKINS-21426) Jenkins Build Fails on Archiving

2014-05-15 Thread kkos...@diio.net (JIRA)















































Ken Koster
 commented on  JENKINS-21426


Jenkins Build Fails on Archiving















This issue may come from the git plugin "Clean before checkout" feature. I was seeing this exact error with that setting turned on, with Jenkins 1.522 and Jenkins Git Plugin 2.2.1. Since turning off the cleaning setting, the ENOENT error hasn't come back (yet).



























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] [git] (JENKINS-22983) The job status should correspond the branch with the worst build status

2014-05-15 Thread roh...@silpion.de (JIRA)

Marc Rohlfs
commented on JENKINS-22983

The job status should correspond the branch with the worst build status

I think Git brings in some different rules here, especially when You consider working with a Git branching model like (or inspired by) the one that is suggested by Vincent Driessen (see http://nvie.com/posts/a-successful-git-branching-model). With Git branching philosophies/methodologies and the Jenkins' Git plugin one of the advantages is that we don't need to create separate jobs for each branch we're actually working on. Would be a pity to loose this advantage.

OK, in the end I cannot judge if more users would prefer one over the other rule reflect the job status. A (global) configuration parameter for this could be a good idea.

And yes, I have to admit that implementing my suggestion wouldn't be trivial. Loading all builds and trying to find the failed or unstable branches is a little unconfident, because relevant builds might have been cleaned up. I'd rather record the branches with failed or unstable builds (e.g. using a file in the job directory), but this also might have some pitfalls.

Anyway, I'd try to implement such a feature if I know that it would be accepted. Otherwise it would not be worth it wasting the time.

p.s.: I see (at least) one more challenge/problem that might also need attention when having a job building several branches: The scores of the Continuous Integration Game plugin might not be reliable ...

[JIRA] [hockeyapp] (JENKINS-22848) Hockeyapp plugin can't publish from remote slaves

2014-05-15 Thread tobias.un...@gridsolut.de (JIRA)















































Tobias Unger
 commented on  JENKINS-22848


Hockeyapp plugin can't publish from remote slaves















I think the file set should be evaluated on the slave using e.g. hudson.remoting.Callable and copied to the master using getFileLocally. Currently, the file set is evaluated on the master using the workspace path of the slave. That's the problem. I've attached a basic example of a Callable. Is anybody working on the issue? Otherwise I'll fix the issue.


launcher.getChannel().call(new RemoteFileTask(build.getWorkspace().getRemote(), vars.expand(filePath)))
 


public class RemoteFileTask implements Callable {

private String basePath;
private String filePath;

public RemoteFileTask(String basePath, String filePath) {
this.filePath = filePath;
this.basePath = basePath;
}

public String call() throws IOException {
FileSet fileSet = Util.createFileSet(new File(basePath),
filePath, null);
return fileSet.iterator().next().toString();
}
}
 



























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] [core] (JENKINS-12998) Allows variable subistution for Job 'Restrict where this project can be run' label expression

2014-05-15 Thread r...@foundatron.com (JIRA)















































Ryan Small
 commented on  JENKINS-12998


Allows variable subistution for Job 'Restrict where this project can be run' label _expression_















+1 I would love to pass a parameter from one job to the next, and assign that parameter value to a node label variable.



























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] [plugin] (JENKINS-23040) Problems with some objects names

2014-05-15 Thread agar...@corlasosa.com (JIRA)













































  
Andres Garcia
 edited a comment on  JENKINS-23040


Problems with some objects names
















The only tool I use is OpenGrok and does not present the same error. The locale LANG environment variable on Linux is en_US.ISO-8859-15.



























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] [coverity] (JENKINS-17467) CoverityPublisher aborted due to NullPointerException

2014-05-15 Thread nickolay.rumyant...@emc.com (JIRA)















































Nickolay Rumyantsev
 commented on  JENKINS-17467


CoverityPublisher aborted due to NullPointerException















I have the same issue as Lee does with Coverity 1.3.1, Jenkins 1.543:
02:05:59.836 ERROR: Publisher jenkins.plugins.coverity.CoverityPublisher aborted due to exception
02:05:59.836 java.lang.NullPointerException
02:05:59.836 	at jenkins.plugins.coverity.analysis.CoverityToolHandler.getHandler(CoverityToolHandler.java:44)
02:05:59.836 	at jenkins.plugins.coverity.CoverityPublisher.perform(CoverityPublisher.java:233)
02:05:59.836 	at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:32)
02:05:59.836 	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785)
02:05:59.836 	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:757)
02:05:59.836 	at hudson.model.Build$BuildExecution.post2(Build.java:183)
02:05:59.836 	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:706)
02:05:59.836 	at hudson.model.Run.execute(Run.java:1703)
02:05:59.836 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
02:05:59.836 	at hudson.model.ResourceController.execute(ResourceController.java:88)
02:05:59.836 	at hudson.model.Executor.run(Executor.java:231)



























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] [core] (JENKINS-22853) SEVERE: Trying to unexport an object that's already unexported

2014-05-15 Thread jgl...@cloudbees.com (JIRA)















































Jesse Glick
 updated  JENKINS-22853


SEVERE: Trying to unexport an object that's already unexported
















Change By:


Jesse Glick
(15/May/14 3:39 PM)




Labels:


remoting



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































stephenconnolly
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















@WH sadly svnkit does not give you that ability. The only thing it lets you have access to is the realm



























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] [clover] (JENKINS-23055) Allow Parameter interpolation for Clover path and file name

2014-05-15 Thread kb...@imprivata.com (JIRA)















































Ken Beal
 created  JENKINS-23055


Allow Parameter interpolation for Clover path and file name















Issue Type:


Bug



Affects Versions:


current



Assignee:


stephenconnolly



Components:


clover



Created:


15/May/14 3:32 PM



Description:


We have branches and projects. We have jobs for each, and would like to unify them so that a single job can be run on multiple branches. Most of the plugins already support using Parameters in their strings (e.g., the Perforce plugin allows us to specify "//depot/${project}/${branchName}" etc).

We would like the Clover Plugin to provide similar functionality.




Environment:


Windows 2008 R2 server, Windows 7 browser




Project:


Jenkins



Priority:


Major



Reporter:


Ken Beal

























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] [parameterized-trigger] (JENKINS-23053) Allow Parameter interpolation for job name

2014-05-15 Thread kb...@imprivata.com (JIRA)















































Ken Beal
 created  JENKINS-23053


Allow Parameter interpolation for job name















Issue Type:


Bug



Affects Versions:


current



Assignee:


huybrechts



Components:


parameterized-trigger



Created:


15/May/14 3:20 PM



Description:


We have branches and projects.  We have jobs for each, and would like to unify them so that a single job can be run on multiple branches.  Most of the plugins already support using Parameters in their strings (e.g., the Perforce plugin allows us to specify "//depot/${project}/${branchName}" etc).

We would like the Parameterized Trigger Plugin to provide similar functionality.




Environment:


Windows 2008 R2 server, Windows 7 browser




Project:


Jenkins



Labels:


interpolation




Priority:


Major



Reporter:


Ken Beal

























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































stephenconnolly
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















@Daniel Beck

Ha! it only seems that way. What happens is that SVNKit caches the realms/connections it has used already and reuses the existing connection from the connection pool. So it is the SVNKit library pulling the security rug out from under us



























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] [gerrit-trigger] (JENKINS-23054) Gerrit trigger doesn't work well with shallow clones (git --depth=1)

2014-05-15 Thread docw...@gerf.org (JIRA)















































Christian Höltje
 updated  JENKINS-23054


Gerrit trigger doesn't work well with shallow clones (git --depth=1)
















Change By:


Christian Höltje
(15/May/14 3:23 PM)




Description:


In order to speed up clones for very large repositories, I want to be able to use shallow clones.Currently, using shallow clones ends up doing the following git commands:{
{
code}
Cloning repository ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
 > git init /a/workspace/engine-copyright-check-gerritFetching upstream changes from ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
 > git --version > git fetch --tags --progress ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
 +refs/heads/*:refs/remotes/origin/* --depth=1 > git config remote.origin.url ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
 > git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* > git config remote.origin.url ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
Fetching upstream changes from ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo
myrepo.git
 > git fetch --tags --progress ssh://
automan@
gerrit.
bigdatalab
example
.
ibm.
com:29418/
vivisimo +
myrepo.git
refs/changes/
*
40
/20740/1
 > git rev-parse FETCH_HEAD^{commit}Checking out Revision e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf (origin/release) > git config core.sparsecheckout > git checkout -f e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf > git rev-parse FETCH_HEAD^{commit} > git rev-list 0ecf38b5c187d237b3689dcd2d5d52ba8c295610{code}I expected something more like
:
refs
{code}Cloning repository ssh:
/
remotes
/
origin
gerrit.example.com:29418
/
myrepo.git > git init /a/workspace/engine-copyright-check-gerritFetching upstream
changes
 from ssh:
/
*
/
gerrit.example.com:29418/myrepo.git > git --version > git fetch --progress ssh://gerrit.example.com:29418/myrepo.git refs/changes/40/
20740/1
 --depth=1
 > git rev-parse FETCH_HEAD^{commit}Checking out Revision e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf (origin/release) > git config core.sparsecheckout > git checkout -f e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf > git rev-parse FETCH_HEAD^{commit} > git rev-list 0ecf38b5c187d237b3689dcd2d5d52ba8c295610
{code
}
The changes are:1. Remove {{--tags
}
} flag2. Fetch only those specific changesThe change, for our repository, is massively faster (a few seconds vs. 3 minutes) and less disk space (40mb vs 3gb).



























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] [gerrit-trigger] (JENKINS-23054) Gerrit trigger doesn't work well with shallow clones (git --depth=1)

2014-05-15 Thread docw...@gerf.org (JIRA)















































Christian Höltje
 created  JENKINS-23054


Gerrit trigger doesn't work well with shallow clones (git --depth=1)















Issue Type:


Bug



Assignee:


rsandell



Components:


gerrit-trigger



Created:


15/May/14 3:21 PM



Description:


In order to speed up clones for very large repositories, I want to be able to use shallow clones.

Currently, using shallow clones ends up doing the following git commands:

{{
Cloning repository ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo
 > git init /a/workspace/engine-copyright-check-gerrit
Fetching upstream changes from ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo
 > git --version
 > git fetch --tags --progress ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo +refs/heads/:refs/remotes/origin/ --depth=1
 > git config remote.origin.url ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo
 > git config remote.origin.fetch +refs/heads/:refs/remotes/origin/
 > git config remote.origin.url ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo
Fetching upstream changes from ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo
 > git fetch --tags --progress ssh://auto...@gerrit.bigdatalab.ibm.com:29418/vivisimo +refs/changes//20740/1:refs/remotes/origin/changes//20740/1
 > git rev-parse FETCH_HEAD^{commit}
Checking out Revision e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf (origin/release)
 > git config core.sparsecheckout
 > git checkout -f e976b99ee4a8b6b65ea351f31c5cd4509a5eafaf
 > git rev-parse FETCH_HEAD^{commit}
 > git rev-list 0ecf38b5c187d237b3689dcd2d5d52ba8c295610
}}




Project:


Jenkins



Priority:


Major



Reporter:


Christian Höltje

























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] [plugin] (JENKINS-23040) Problems with some objects names

2014-05-15 Thread agar...@corlasosa.com (JIRA)













































  
Andres Garcia
 edited a comment on  JENKINS-23040


Problems with some objects names
















The only tool I use is OpenGrok and does not present the same error. The locale LANG environment variable on Linuxis en_US.ISO-8859-15.



























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] [git] (JENKINS-23052) Shallow clones should only pass '--tags' if opted-in

2014-05-15 Thread docw...@gerf.org (JIRA)















































Christian Höltje
 created  JENKINS-23052


Shallow clones should only pass '--tags' if opted-in















Issue Type:


Bug



Assignee:


Nicolas De Loof



Components:


git



Created:


15/May/14 3:06 PM



Description:


When using "Advanced clone behaviors" -> "Shallow Clone" the git command line looks like this:

git fetch --tags --progress ssh://gerrit.example.com:29418/myrepo +refs/heads/:refs/remotes/origin/ --depth=1

The --tags causes everything (or darn near close) on our repo because we tag every build in Jenkins.

There should be a way to turn it off and it should probably be opt-in (but I'm not sure).




Project:


Jenkins



Priority:


Major



Reporter:


Christian Höltje

























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































Daniel Beck
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















WH

Why not implementing this solution? It would solve the orginal error of this issue.

I'm sure a pull request by anyone wishing to provide this would be appreciated by many.



stephenconnolly How does that work given that regular checkout simply reuses the same credential for checking out any externals? If the job configurer provides a sufficiently powerful credential, then any externals will also be checked out. It's only when an external cannot be checked out using the configured credential that it falls back to Additional Credentials.

Therefore I consider it a viable solution to annotate any external location in the project with the module location that introduced it to reuse its credential – at least that's not brute-forcing credentials like in 1.x.



























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] [plugin] (JENKINS-23040) Problems with some objects names

2014-05-15 Thread agar...@corlasosa.com (JIRA)















































Andres Garcia
 commented on  JENKINS-23040


Problems with some objects names















The only tool I use is OpenGrok and does not present the same error. The locale is en_US.ISO-8859-15.



























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] [git-parameter] (JENKINS-23051) Support regular expression when filtering tags















































ngiger
 created  JENKINS-23051


Support regular _expression_ when filtering tags















Issue Type:


Bug



Assignee:


Niklaus Giger



Components:


git-parameter



Created:


15/May/14 2:54 PM



Description:


It should be possible to use a regular _expression_ for filtering tags to e.g. to select all alpha or beta releases.




Project:


Jenkins



Priority:


Major



Reporter:


ngiger

























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] [git-parameter] (JENKINS-22886) Does not fetch/list current/new tags















































ngiger
 commented on  JENKINS-22886


Does not fetch/list current/new tags















This behavious is documented on the wiki page, when there has never been any build.

I tried to work around this issue and it should work now (Release 0.3.2) after a first build, regardless whether the workspace was wiped out or not.

Is this good enough for you?



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

2014-05-15 Thread hinr...@prostep.com (JIRA)















































WH
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















@stephenconnolly:
Thanks for the background informations. How about a list of "allowed URLs of externals"?



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































stephenconnolly
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















@Christoph: that would be another approach that is equally valid... I suspect the pair of both defaulting ignoreExternals to on and providing an option to reuse module credentials where matching would be the best of breed solution



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































stephenconnolly
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















the svnkit library has been known to leak some credentials anyway...



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

2014-05-15 Thread jenk...@mockies.de (JIRA)













































  
Christoph Vogtländer
 edited a comment on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials
















stephenconnolly: consider /trunk/publicproject needs an (svn:externals) to /trunk/sharedlib. The user can then still just add the external definition to /trunk/secretproject and will be able to get the code. You are right where you started before the changes. There is nothing you can do here. IMHO the current behaviour is not adding security but only complexity/obscurity, which is always bad. If you run a public Jenkins instance using a subversion repository with non public code you have to know what you are doing. I think this scenario should be documented on the plug-in page to make sysadmins aware. But I don't think that this is solvable in the plug-in without adding even more complexity.
Maybe it would be better to default "Ignore externals" to "on" and in case the user switches this off notify the user about the possible pitfalls. He can then easily decide to just configure the external explicitly as an additional module.



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

2014-05-15 Thread jenk...@mockies.de (JIRA)















































Christoph Vogtländer
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















stephenconnolly: consider /trunk/publicproject needs an (svn:externals) to /trunk/sharedlib. The user can then still just add the external definition to /trunk/secretproject and will be able to get the code. You are right where you started before the changes. There is nothing you can do here. IMHO the current behaviour is not adding security but only complexity/obscurity, which is always bad. If you run a public Jenkins instance using a subversion repository with non public code you have to know what you are doing. I think this scenario should be documented on the plug-in page to make sysadmins aware. But I don't think that this is solvable in the plug-in without adding even more complexity.



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































michael soukup
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















stephenconnolly: thank you for the clarification.
What I still don't understand regarding this is: the checkout does not always fail (it uses the credentials from the parent project in some cases as e.g. a manual build request or clean checkout as binary mentioned). This would be the security issue you mentioned.

What does fail is the revision check on the external project.



























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] [pmd] (JENKINS-10820) PMD plugin does not find report files

2014-05-15 Thread ullrich.haf...@gmail.com (JIRA)















































Ulli Hafner
 commented on  JENKINS-10820


PMD plugin does not find report files















@Jean-Pierre Froud: Please do not comment on resolved issues that might be similar: either create a new issue or discuss your problem in the mailing list before you create the issue (latter is preferred). So we see if this is actually a bug or just 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] [subversion] (JENKINS-17103) Apply credentials also to separate server used from svn:externals















































stephenconnolly
 commented on  JENKINS-17103


Apply credentials also to separate server used from svn:externals















This is a necessary security fix to resolve a vulnerability whereby commit access to one portion of a subversion repository can be used to hijack Jenkins' credentials (which are typically global read) to gain read access to the rest of the repository. A valid enhancement request would be a checkbox to allow opting in to using the module credentials on matching externals



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

stephenconnolly
commented on JENKINS-21785

Check for changes in folders linked via svn:externals fails due to missing credentials

Just to clarify why externals need their own credentials.

There is a security risk in using Jenkins' credentials to checkout an external even if the external is the exact same repo as the module you are checking out.

Consider the case where a developer has commit access to /trunk/publicproject in the repo but does not have read access to /trunk/secretproject

The Jenkins admin has locked down Jenkins so that the developer cannot modify the Jenkins jobs.

With the old behaviour, the developer could just commit to /trunk/publicproject adding an svn:external to checkout /trunk/secretproject and modify the build script to tar up the external checkout and email it to themselves... ok they have left a track of what they did, but now the secret project code is no-longer secret... now consider the case where it was that the developer's computer was stolen or hacked.

You could argue that the correct way to handle that would be to give Jenkins two credentials, the first that is scoped to /trunk/publicproject and the second scoped to /trunk/secretproject... well with the old 1.x way Jenkins would just try all credentials until it found one that works... so still lost there

With 2.x you could do that but now you have to remember to use the correct credentials for the correct paths (ok, so credential domains can help there, but it does get a lot more complex... and there are cases where you cannot)

So given that most people just give Jenkins a credential that has read access everywhere, the only safe way to handle externals is to require configuring the credentials to use when checking out the external.

[JIRA] [subversion] (JENKINS-17103) Apply credentials also to separate server used from svn:externals















































michael soukup
 commented on  JENKINS-17103


Apply credentials also to separate server used from svn:externals















Nice feature.

The only issue I (and some others) have with this is - you must specify additional credentials now for all your external projects, even if they are on the same server.
see JENKINS-21785
maybe you could use the additional credentials only if the already provided credentials for the repository fail. Otherwise the workaround makes it a necessity to edit a lot of jobs.



























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] [groovy-postbuild] (JENKINS-15210) Add variable resolution to "additional groovy class path"

2014-05-15 Thread martin.danjo...@gmail.com (JIRA)















































Martin d'Anjou
 commented on  JENKINS-15210


Add variable resolution to "additional groovy class path"















I think this is a duplicate of JENKINS-21480



























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] [groovy-postbuild] (JENKINS-21480) Groovy postbuild add ability to use external groovy script

2014-05-15 Thread martin.danjo...@gmail.com (JIRA)















































Martin d'Anjou
 commented on  JENKINS-21480


Groovy postbuild add ability to use external groovy script















I think this is a duplicate of JENKINS-15210



























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] [master-slave] (JENKINS-10376) When running Windows JNLP slaves, all of my remote builds fail with java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Laun

2014-05-15 Thread scott.laven...@gmail.com (JIRA)













































  
Scott Lavender
 edited a comment on  JENKINS-10376


When running Windows JNLP slaves, all of my remote builds fail with java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher
















Platform: Windows 7

I recently moved three Windows slaves to a new Jenkins master. Some of my Maven build jobs throw this same exception. If I move the jobs to a Linux slave, they run fine. I was thinking that it may have to do with the old workpsaces, so I purged the workspace folder and brought the Windows slaves back online. The issue persists.

ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-us...@googlegroups.com
java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher
	at hudson.remoting.Which.classFileUrl(Which.java:60)
	at hudson.remoting.Which.jarFile(Which.java:82)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:525)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:521)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:328)
	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.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
project=hudson.maven.MavenModuleSet@89ec211[B2014_6_1_build-equicom-partner-webservices]
project.getModules()=[hudson.maven.MavenModule@59816e9a[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws][relativePath:../equicom-partner-ws], hudson.maven.MavenModule@40846e5e[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][relativePath:], hudson.maven.MavenModule@68bdbb67[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-client][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-client][relativePath:../equicom-partner-ws-client], hudson.maven.MavenModule@3cf3c6d4[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-common][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-common][relativePath:../equicom-partner-ws-common], hudson.maven.MavenModule@2882a78f[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-config][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-config][relativePath:../equicom-partner-ws-config], hudson.maven.MavenModule@1c1474ba[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-deployable][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-deployable][relativePath:equicom-partner-ws-deployable], hudson.maven.MavenModule@51f18c5f[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-emulation][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-emulation][relativePath:../equicom-partner-ws-emulation], hudson.maven.MavenModule@4936db00[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-web][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-web][relativePath:../equicom-partner-ws-web]]
project.getRootModule()=hudson.maven.MavenModule@40846e5e[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][relativePath:]
FATAL: Unable to locate class file for class hudson.remoting.Launcher
java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher
	at hudson.remoting.Which.classFileUrl(Which.java:60)
	at hudson.remoting.Which.jarFile(Which.java:82)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(Abstract

[JIRA] [master-slave] (JENKINS-10376) When running Windows JNLP slaves, all of my remote builds fail with java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Laun

2014-05-15 Thread scott.laven...@gmail.com (JIRA)















































Scott Lavender
 commented on  JENKINS-10376


When running Windows JNLP slaves, all of my remote builds fail with java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher















I recently moved three Windows slaves to a new Jenkins master. Some of my Maven build jobs throw this same exception. If I move the jobs to a Linux slave, they run fine. I was thinking that it may have to do with the old workpsaces, so I purged the workspace folder and brought the Windows slaves back online. The issue persists.

ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-us...@googlegroups.com
java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher
	at hudson.remoting.Which.classFileUrl(Which.java:60)
	at hudson.remoting.Which.jarFile(Which.java:82)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:525)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:521)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:328)
	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.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
project=hudson.maven.MavenModuleSet@89ec211[B2014_6_1_build-equicom-partner-webservices]
project.getModules()=[hudson.maven.MavenModule@59816e9a[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws][relativePath:../equicom-partner-ws], hudson.maven.MavenModule@40846e5e[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][relativePath:], hudson.maven.MavenModule@68bdbb67[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-client][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-client][relativePath:../equicom-partner-ws-client], hudson.maven.MavenModule@3cf3c6d4[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-common][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-common][relativePath:../equicom-partner-ws-common], hudson.maven.MavenModule@2882a78f[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-config][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-config][relativePath:../equicom-partner-ws-config], hudson.maven.MavenModule@1c1474ba[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-deployable][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-deployable][relativePath:equicom-partner-ws-deployable], hudson.maven.MavenModule@51f18c5f[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-emulation][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-emulation][relativePath:../equicom-partner-ws-emulation], hudson.maven.MavenModule@4936db00[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-web][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-web][relativePath:../equicom-partner-ws-web]]
project.getRootModule()=hudson.maven.MavenModule@40846e5e[B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][B2014_6_1_build-equicom-partner-webservices/com.equifax.gis.equicom:equicom-partner-ws-aggregator][relativePath:]
FATAL: Unable to locate class file for class hudson.remoting.Launcher
java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher
	at hudson.remoting.Which.classFileUrl(Which.java:60)
	at hudson.remoting.Which.jarFile(Which.java:82)
	at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:5

[JIRA] [credentials] (JENKINS-22078) SVN fails revision check for external subprojects















































michael soukup
 updated  JENKINS-22078


SVN fails revision check for external subprojects
















Change By:


michael soukup
(15/May/14 1:32 PM)




Description:


h2. Since version 2.0 you have to add additional credits to your jobs with externals. You need to reconfigure them as described in [JENKINS-21785]. This is behaviour by design and not a bug.
our projects have externals specified which lie on the same server (also in the same repository).The external project reference is specified as relative path:{code}^/trunk/Library{code}Up to end of February the check for changes was working correctly.After a complete update on Feb. 28th (to 1.553 and also all plugins) the revision check on the externals fails and only works for the main project, making Jenkins think that there are no changes and skipping the automatic build:{code:title=Last Subversion Protokoll}Started on 07.03.2014 08:51:40Received SCM poll call on  for LIBS mit Halcon11 on 07.03.2014 08:51:40ERROR: Failed to check repository revision for https://[Server]/svn/IAB2.5/trunk/Libraryorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/IAB2.5/trunk/Library failed	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)	at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)	at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1266)	at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)	at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)	at hudson.remoting.LocalChannel.call(LocalChannel.java:45)	at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1451)	at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)	at hudson.scm.SCM.poll(SCM.java:373)	at hudson.model.AbstractProject._poll(AbstractProject.java:1584)	at hudson.model.AbstractProject.poll(AbstractProject.java:1493)	at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462)	at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491)	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)	at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)	at java.util.concurrent.FutureTask.run(Unknown Source)	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)	at java.lang.Thread.run(Unknown Source)Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: 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.cor

[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

2014-05-15 Thread hinr...@prostep.com (JIRA)















































WH
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















I hope I understood it right.

The problem is:
"No such "inheritance" or association to an explicitly configured location exists for externals when polling for changes [...]"

The solution is:
"Adding this association, or just adding all credentials already used in the project for any external [...]"

Why not implementing this solution? It would solve the orginal error of this issue.



























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] [managed-scripts] (JENKINS-20963) Allow managed scripts to be called from a post build task

2014-05-15 Thread dominik...@gmail.com (JIRA)













































  
Dominik Ruf
 edited a comment on  JENKINS-20963


Allow managed scripts to be called from a post build task
















I'm willing to help with this.
Would you accept a merge request if I implement 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/d/optout.

[JIRA] [managed-scripts] (JENKINS-20963) Allow managed scripts to be called from a post build task

2014-05-15 Thread dominik...@gmail.com (JIRA)















































Dominik Ruf
 commented on  JENKINS-20963


Allow managed scripts to be called from a post build task















I'm willing to help with this.
Would you accept a merge request when I implement 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/d/optout.

[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials













































  
michael soukup
 edited a comment on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials
















Daniel Beck: as I wrote a few comments ago I too see this as a workaround as the plugin upgrade broke the behaviour (it was working without additional credentials before 2.0) - but I can live with the workaround and I also can follow your explanation (check out vs. change detection)

Maybe you could rephrase your entry in the bug description anyway to make it clearer as your bugfixes do not match the description of the bug entry and thus the bug is not fixed but the behaviour still intended.
Maybe something like 
"Since version 2.0 you have to add additional credits to your jobs with externals. You need to reconfigure them as described in the comments below. This behaviour is intended and not a bug." 
would be clearer.



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials















































michael soukup
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















Daniel Beck: as I wrote a few comments ago I too see this as a workaround as the plugin upgrade broke the behaviour (it was working without additional credentials before 2.2) - but I can live with the workaround and I also can follow your explanation (check out vs. change detection)

Maybe you could rephrase your entry in the bug description anyway to make it clearer as your bugfixes do not match the description of the bug entry and thus the bug is not fixed but the behaviour still intended.
Maybe something like 
"Since version 2.2 you have to add additional credits to your jobs with externals. You need to reconfigure them as described in the comments below. This behaviour is intended and not a bug." 
would be clearer.



























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] (JENKINS-22930) Subversion Parameters show "Repository URL" instead of the name

2014-05-15 Thread andy.b...@thomsonreuters.com (JIRA)















































Andy Beck
 updated  JENKINS-22930


Subversion Parameters show "Repository URL" instead of the name
















Change By:


Andy Beck
(15/May/14 1:14 PM)




Attachment:


screenshot_of_defect.png



























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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow















































ikedam
 commented on  JENKINS-23012


Build-timeout plugin causes builds to slow















As those synchronized methods are called at the start and the end of builds, I don't think they cause being slow.

Rather, changes to watch log outputs may cause the problem.
https://github.com/jenkinsci/build-timeout-plugin/commit/2129c5d8fc4a9d9432cf95ce34ce522e646eb3ff#diff-891dfa43e0d85dea7162d46b430299d7R184

I want to make some testing versions to identify the cause.
But I'm not sure how to reproduce the problem.

Can you try testing versions if I provide?




























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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
















































ikedam
 assigned  JENKINS-23012 to ikedam



Build-timeout plugin causes builds to slow
















Change By:


ikedam
(15/May/14 1:13 PM)




Assignee:


Kohsuke Kawaguchi
ikedam



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

Daniel Beck
commented on JENKINS-21785

Check for changes in folders linked via svn:externals fails due to missing credentials

binary: Please provide some references (i.e. code) for your claims. Because that's not how the plugin works AFAICT.

Externals that are checked out inherit the credential defined for the location which is explicitly being checked out (e.g. SVNUpdateClient.doCheckout() call). Only if these don't work, Additional Credentials are needed.

No such "inheritance" or association to an explicitly configured location exists for externals when polling for changes, they're just another location (automatically, by the plugin) defined in the project – but one without explicitly specified credentials, requiring fallback to Additional Credentials immediately.

Adding this association, or just adding all credentials already used in the project for any external being checked out, would be an improvement. And these are the only options I see right now for the 'Improvement' to go.

[JIRA] [git] (JENKINS-23050) Slave unable to clone from Git over HTTPS due to self signed certificate

2014-05-15 Thread arve.knud...@gmail.com (JIRA)















































Arve Knudsen
 updated  JENKINS-23050


Slave unable to clone from Git over HTTPS due to self signed certificate
















Change By:


Arve Knudsen
(15/May/14 12:35 PM)




Description:


My slave is unable to clone from Git over HTTPS (via Git plugin version 2.2.1, Git client plugin version 1.9.0), due to the server's self signed certificate. The reason is that Java doesn't find the server's certificate in its store, even though the Git command line client has no problems with it. The error looks as follows:FATAL: Failed to fetch from https://myserver/repo.githudson.plugins.git.GitException: Failed to fetch from https://myserver/repo.gitat hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:623)at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:855)at hudson.plugins.git.GitSCM.checkout(GitSCM.java:880)at hudson.model.AbstractProject.checkout(AbstractProject.java:1251)at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:513)at hudson.model.Run.execute(Run.java:1706)at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)at hudson.model.ResourceController.execute(ResourceController.java:88)at hudson.model.Executor.run(Executor.java:231)Caused by: hudson.plugins.git.GitException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetat org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1964)at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1143)at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257)at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)at hudson.remoting.UserRequest.perform(UserRequest.java:118)at hudson.remoting.UserRequest.perform(UserRequest.java:48)at hudson.remoting.Request$2.run(Request.java:328)at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)at java.util.concurrent.FutureTask.run(Unknown Source)at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)at hudson.remoting.Engine$1$1.run(Engine.java:63)at java.lang.Thread.run(Unknown Source)
See also StackOverflow: http://stackoverflow.com/questions/23678127/how-do-i-connect-to-a-jenkins-slave-to-a-git-server-with-self-signed-certificate.



























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] [build-timeout] (JENKINS-23018) Absolute build timeout doesn't stop the build















































ikedam
 commented on  JENKINS-23018


Absolute build timeout doesn't stop the build















Build-timeout plugin starts its timer AFTER scm phase.
And so it never catches timeout of SCM.



























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] [git] (JENKINS-23050) Slave unable to clone from Git over HTTPS due to self signed certificate

2014-05-15 Thread arve.knud...@gmail.com (JIRA)















































Arve Knudsen
 created  JENKINS-23050


Slave unable to clone from Git over HTTPS due to self signed certificate















Issue Type:


Bug



Affects Versions:


current



Assignee:


Nicolas De Loof



Components:


git, git-client



Created:


15/May/14 12:34 PM



Description:


My slave is unable to clone from Git over HTTPS (via Git plugin version 2.2.1, Git client plugin version 1.9.0), due to the server's self signed certificate. The reason is that Java doesn't find the server's certificate in its store, even though the Git command line client has no problems with it. The error looks as follows:

FATAL: Failed to fetch from https://myserver/repo.git
hudson.plugins.git.GitException: Failed to fetch from https://myserver/repo.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:623)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:855)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:880)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1251)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:513)
at hudson.model.Run.execute(Run.java:1706)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: hudson.plugins.git.GitException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1964)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1143)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:63)
at java.lang.Thread.run(Unknown Source)




Environment:


Windows 7 SP1 x64




Project:


Jenkins



Labels:


plugin
git
git-client
git-plugin
ssl
slave
certificate




Priority:


Major



Reporter:


Arve Knudsen

























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

[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

2014-05-15 Thread andrejs.sit...@gmail.com (JIRA)















































binary
 commented on  JENKINS-21785


Check for changes in folders linked via svn:externals fails due to missing credentials















Try deleting workspace and running the build, it will succeed without additional credentials, all externals will be checked out. This means that additional credentials are not required. This also means that fixing exception "No credentials to try", when sources in externals are changed, would be a bugfix, not an improvement (those changes are still checked out before an exception).



























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] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block

2014-05-15 Thread gsz...@gmail.com (JIRA)













































  
Gergely Nagy
 edited a comment on  JENKINS-20292


Option to specify an else-block
















I absolutely agreed, some of my conditions are so much messier due to the repetition - that I've fallen back to edit the config.xml via API.
(BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.)

I'm considering working on this - unless experts owners disagree or think it's really tricky to do.



























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] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block

2014-05-15 Thread gsz...@gmail.com (JIRA)













































  
Gergely Nagy
 edited a comment on  JENKINS-20292


Option to specify an else-block
















I absolutely agreed, some of my conditions are so much messier due to the repetition - that I've fallen back to edit the XML.
(BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.)

I'm considering working on this - unless experts owners disagree or think it's really tricky to do.



























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] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block

2014-05-15 Thread gsz...@gmail.com (JIRA)















































Gergely Nagy
 commented on  JENKINS-20292


Option to specify an else-block















I absolutely agreed, some of much conditions are so much messier due to the repetition - that I've fallen back to edit the XML.
(BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.)

I'm considering working on this - unless experts owners disagree or think it's really tricky to do.



























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] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials