[JIRA] (JENKINS-38053) JellyTagException on Multijob project view with Jenkins 2.7.3 LTS
Title: Message Title Caleb Mayeux commented on JENKINS-38053 Re: JellyTagException on Multijob project view with Jenkins 2.7.3 LTS Also seeing the same here on Jenkins 1.642.3 and 1.642.18.3. Also don't see issue on 1.21. Tried making a fresh multijob, and the job screen appears with no issue. The stacktrace appears when I add a "Trigger/call builds on other projects" build step from the Parameterized Trigger Plugin to a Multijob. Take it out, and the job screen doesn't have a stacktrace. Hopefully that tidbit helps narrow down the issue. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-plugin] (JENKINS-16797) Coverity plugin insert cov-build commands into perforce workspace causing P4 to fail
Title: Message Title Caleb Mayeux resolved as Not A Defect I know this bug is three years old, but ran into this myself, and wanted to update for those who still might run into it. It's not really a defect - it's a configuration issue. By default coverity wraps all the commands, but there's a field, "cov-build blacklist", where you put a comma-delimited list of commands that shouldn't be wrapped. Thus, the proper configuration where this will work is to put the path to your p4 executable in that field, something like: /auto/perforce/p4bin/current/p4. Then you can checkout without issue. Also you can use the newer P4 Jenkins plugin (as opposed to the Perforce Plugin) that's supported by perforce itself, and it doesn't require this configuration. Hope this helps. Jenkins / JENKINS-16797 Coverity plugin insert cov-build commands into perforce workspace causing P4 to fail Change By: Caleb Mayeux Status: Open Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [perforce-plugin] (JENKINS-26999) Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Title: Message Title Caleb Mayeux commented on JENKINS-26999 Re: Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27) Hey Peter, It's been quite a while since I looked at this, but I remember the issue is that the polling environment doesn't have the full build environment context. Not sure how you would hack the envinject plugin to do that, not to mention the fact that it would generally be unwise to introduce a dependency to the perforce plugin in the envinject plugin. If you've got Cloudbees support, you can try to use some of their templating features to inject the actual password (encrypted) into the xml of the job config. Otherwise, probably your best bet, if you are mostly just using one set of credentials per Jenkins instance, is to use the global username/password. Alternately you can use the perforce plugin put out by perforce itself, which if I'm not mistaken uses Jenkins credentials (though honestly overall I'm not as keen on that plugin as this one, even though that one is the "official" Jenkins plugin). Caleb Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [perforce-plugin] (JENKINS-28522) masked variable in p4 passwd causes labelling problem
Title: Message Title Caleb Mayeux commented on JENKINS-28522 Re: masked variable in p4 passwd causes labelling problem I was going to open a new bug due to a similar issue, but I believe the root cause may be the same. My issue is that I have the perforce password as an environment variable set at the beginning of the build (technically through the cloudbees folders plus capability for folders to have environment variables, but works the same if you say, inject the environment variable at the beginning of the build). The macro is resolved correctly for the checkout, but fails to resolve if the label portion is used. I looked at how the variables are being dereferenced, and for getting the decrypted password for the label portion, rather than using the build's environment, only a barebones number of macros are being passed to the substitution, resulting in the same unresolved macro error. I replaced a single line in src/main/java/hudson/plugins/perforce/PerforceTagAction.java: 190 depot.setPassword(scm.getDecryptedP4Passwd(this.getBuild().getProject(), this.getBuild().getBuiltOn())); with 190 depot.setPassword(scm.getDecryptedP4Passwd(this.getBuild())); and after that it works fine in my test environment. I know this plugin has been eclipsed by the official perforce one, but it's an easy fix. Hey Rob, do you still plan on releasing with patches like this? Should I do a pull request? Thanks, Caleb Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] [coverity-plugin] (JENKINS-30804) Allow Coverity Connect credential override at job level
Title: Message Title Caleb Mayeux created an issue Jenkins / JENKINS-30804 Allow Coverity Connect credential override at job level Issue Type: Improvement Assignee: Ken Dang Components: coverity-plugin Created: 05/Oct/15 8:06 PM Environment: Jenkins 1.580.3 Coverity plugin 1.5.1 Labels: coverity credentials Priority: Major Reporter: Caleb Mayeux Currently the Coverity Connect instances defined globally in Jenkins hold the CIM connection information and credentials. However, this means that any job in Jenkins can use the global credentials to connect and upload data to any Coverity instance configured in Jenkins. This doesn't work well in large, shared, enterprise Jenkins instances. If the Coverity plugin allowed the jobs to override the username/password supplied in a global Coverity Connect instance, then global Coverity Connect instances could optionally be configured without supplying credentials, forcing the jobs to supply them. This would prevent global access to Coverity instances, allowing the Jenkins
[JIRA] [perforce-plugin] (JENKINS-26999) Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Caleb Mayeux commented on JENKINS-26999 Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27) @Oleg Thanks for the quick response! Wow, I feel pretty stupid. So turns out, it always worked previously because the first time it went to poll, it'd find no prior builds and thus start a build. Subsequently, the polling process would just reuse the ticket acquired from the login of the previous build, never actually relying on the credentials in the job. When I updated the perforce plugin, I also rebooted the Jenkins instance, for the first time in a very long time, which apparently cleared all the cached tickets, breaking polling across all my jobs. When I reverted the plugin and retried with the old plugin, first I had manually hit some builds, which refreshed the stored tickets, giving the illusion of it working with the old version but not the new version. Sorry for the misdirection! And yep, you were right that my polling procedures weren't completely correct. Can close as invalid. 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-plugin] (JENKINS-26999) Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Caleb Mayeux resolved JENKINS-26999 as Not A Defect Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27) User configuration error, not a defect. Change By: Caleb Mayeux (18/Feb/15 6:21 PM) Status: InProgress Resolved Resolution: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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-plugin] (JENKINS-26999) Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Caleb Mayeux closed JENKINS-26999 as Not A Defect Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27) Change By: Caleb Mayeux (18/Feb/15 6:21 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-plugin] (JENKINS-26999) Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Caleb Mayeux
created JENKINS-26999
Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Issue Type:
Bug
Assignee:
Rob Petti
Components:
perforce-plugin
Created:
17/Feb/15 8:42 PM
Description:
After recently upgrading from 1.3.27 to 1.3.33, job polling appears to be failing with unresolved macro issues trying to poll when using perforce plugin in conjunction with Environment Injector plugin.
I have a global password in the global config. In the job config, I have that variable name, let's say MY_P4PASSWD, set in the field for the perforce password. Also in the job config I have the "Inject passwords to the build as environment variables" and the "Global passwords" box checked under that.
The variable is correctly resolved during the checkout, however no longer resolves during polling or during labeling. It all worked fine in 1.3.27. Also I reverted plugin version and tested that it wasn't any other variable in configuration.
Snippet of stack trace from polling:
FATAL: ${MY_P4PASSWD}: Found unresolved macro at '${MY_P4PASSWD}'
hudson.plugins.perforce.utils.ParameterSubstitutionException: ${MY_P4PASSWD}: Found unresolved macro at '${MY_P4PASSWD}'
at hudson.plugins.perforce.utils.MacroStringHelper.checkString(MacroStringHelper.java:154)
at hudson.plugins.perforce.utils.MacroStringHelper.substituteParameters(MacroStringHelper.java:102)
at hudson.plugins.perforce.PerforceSCM.getDecryptedP4Passwd(PerforceSCM.java:2700)
at hudson.plugins.perforce.PerforceSCM.getDepot(PerforceSCM.java:487)
at hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1310)
at hudson.scm.SCM.poll(SCM.java:401)
Environment:
Jenkins 1.580.3
perforce plugin 1.3.33
Environment Injector (EnvInject) plugin 1.90
Project:
Jenkins
Priority:
Major
Reporter:
Caleb Mayeux
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] [multijob-plugin] (JENKINS-26715) Multijob plugin support for polling subjobs
Caleb Mayeux created JENKINS-26715 Multijob plugin support for polling subjobs Issue Type: Improvement Assignee: Caleb Mayeux Components: multijob-plugin Created: 30/Jan/15 5:08 PM Description: It would be nice if a multijob job could optionally poll its children in addition to itself when polling for changes. Rationale for enhancement: The multijob type is ideal for componentized builds which can be built as individual components or together as a large package, by grouping individual standalone jobs that can be built in parallel. However, those standalone components can have their own SCM checkout steps different from the multijob itself (in my case the multijob is a container with no SCM checkout), which means the multijob that contains them can't detect whether or not there are changes when polling. Super simplified scenario I'm facing: Suppose you have a multijob that is merely a container for subjobs A, B, and C. A checks out code, B builds a component, and C does some bundling. In this configuration, there is no way to poll for changes without going outside of the multijob plugin and thus losing the benefits of it. Environment: Jenkins 1.580.2, multijob-plugin 1.16, RHEL 5.5 Project: Jenkins Priority: Major Reporter: Caleb Mayeux 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] [multijob-plugin] (JENKINS-26715) Multijob plugin support for polling subjobs
Caleb Mayeux commented on JENKINS-26715 Multijob plugin support for polling subjobs Created pull request #62 to add this feature. 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-24186) Add option for deleting perforce clients
Caleb Mayeux created JENKINS-24186 Add option for deleting perforce clients Issue Type: Improvement Assignee: Rob Petti Components: perforce Created: 08/Aug/14 8:54 PM Description: It would be much more efficient to have an option for Jenkins to delete the workspace at the end of the build job. While the Jenkins perforce plugin is really good about creating and managing workspaces, currently it ends up creating lots of clients/workspaces without cleaning any up. Since the perforce server has to track a lot of metadata on each client workspace (records on each of the files that are checked out), it can severely limit the scalability of the Jenkins/perforce plugin using workspace management. In a production atmosphere with hundreds to thousands of jobs that can run on different nodes, the perforce server can even run out of RAM loading all the client records into memory. This often leads to the perforce admin hunting down members of the devops team. Environment: Jenkins 1.554.2, perforce plugin 1.3.27, RHEL 5.5 Project: Jenkins Priority: Major Reporter: Caleb Mayeux 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-24186) Add option for deleting perforce clients
Caleb Mayeux commented on JENKINS-24186 Add option for deleting perforce clients True, unless you're using the force sync option and wiping your workspace at the end of each build anyway. Maybe it could be a checkbox under the force sync option? I have no idea how typical this workflow is, but ours relies on us wiping the workspace and force syncing each time. This is done because for a number of branches across a large pool of nodes, there isn't near enough storage space on each build slave to keep a sync'ed workspace on each (Dealing with a few hundred branches of 5-10GB workspace size in each, and a pool of a couple dozen nodes = 100s * (5-10)GB * ~ 24 = many terabytes of expensive SAN). Typical space/bandwidth tradeoff, with a local perforce proxy keeping the traffic across the WAN to a minimum. Additionally, it keeps builds from being contaminated by old artifacts. Also this proposed enhancement would probably be useful for jobs that are run only rarely. 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-24186) Add option for deleting perforce clients
Caleb Mayeux commented on JENKINS-24186 Add option for deleting perforce clients 1) True, there is an very easy workaround adding the command as the last step or post build task. It'd just be cleaner inside the plugin (arguably the opposite if you're not using it and concerned about bloat). 2) Yes, it has become an incredibly flexible plugin. 3) Took a look at the code (guess I should've done that part first). I was originally thinking it'd be a checkbox under force sync, which would be pretty attractive. Looking at the SCM class though, the only obvious way I can see to do it would be to add it as a separate post-build step - similar to the way the labeling works (I'm assuming that's why the labeling portion isn't grouped with the rest of the plugin). A post-build step just for that option would be almost as annoying as having to add a generic step with the command line command, so I'm somewhat inclined to side with your reluctance on this feature. Well, thanks for the time and input! Perhaps we can leave this ticket open for a month or so and see if anyone else wants to weigh in, then close it out? 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
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 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
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: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [perforce] (JENKINS-23058) Perforce plugin tickets failing
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] [parameterized-trigger] (JENKINS-22229) Build from properties file fails if workspace does not exist
Caleb Mayeux commented on JENKINS-9 Build from properties file fails if workspace does not exist @ikeadam, yes, I'd like the plugin to support absolute or relative (to workspace) path, with support for token macros (variables). I'm not really asking for a new feature, as this support already exists. There's just a few lines of code that were introduced that skip the path resolution if the workspace was already deleted that I'd like to remove. I did a pull request for this here: https://github.com/jenkinsci/parameterized-trigger-plugin/pull/64 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-22229) Build from properties file fails if workspace does not exist
Caleb Mayeux
created JENKINS-9
Build from properties file fails if workspace does not exist
Issue Type:
Bug
Affects Versions:
current
Assignee:
huybrechts
Components:
parameterized-trigger
Created:
17/Mar/14 4:43 PM
Description:
Due to a change implemented in JENKINS-21013(FileBuildParameters.java: ~100), if the workspace does not exist, the attempt to read parameters from that file is skipped. However, there is nothing that restricts the parameter file to be in the workspace, so the check is inaccurately flagging that the parameter file doesn't need to be searched for.
I place parameter files in ${WORKSPACE}/.. so that I could use the workspace cleanup plugin along with the trigger parameterized build plugin. Since the workspace is cleaned up on jobs first, now the parameterized build trigger skips the check and doesn't read the parameter file, even though it exists. I would think this is a fairly typical use case scenario, but have no evidence to support this.
It would be nice if that check was taken out, so parameter files could once again be anywhere on the build slave.
Environment:
RHEL 5.5, Jenkins 1.551, parameterized trigger 2.23 and later.
Project:
Jenkins
Priority:
Minor
Reporter:
Caleb Mayeux
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-remote-trigger] (JENKINS-22231) Allow parameterized remote trigger to be a post-build action
Caleb Mayeux created JENKINS-22231 Allow parameterized remote trigger to be a post-build action Issue Type: Improvement Assignee: Maurice W. Components: parameterized-remote-trigger Created: 17/Mar/14 5:14 PM Description: Currently parameterized remote trigger plugin can run a remote job as a build step. It would be pretty nice if it could be a post-build action as well as a build step, like the vanilla parameterized trigger plugin. This can of course be worked around, but it'd still be nice. Awesome plugin, by the way! Environment: RHEL 5.5, Jenkins 1.551, parameterized-remote-trigger plugin 2.1 Project: Jenkins Priority: Major Reporter: Caleb Mayeux 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-18578) Default jar cache location is hardcoded to ~/.jenkins/cache/jars and not configurable
Caleb Mayeux commented on JENKINS-18578 Default jar cache location is hardcoded to ~/.jenkins/cache/jars and not configurable Another workaround is to use what Mr. Kohsuke said: In the slave configuration, under the Advanced method of Launch Option, Put the following in the Suffix Start Slave Command " -jar-cache path to jar cache directory" (no quotes) Make sure there's a leading space so the parameters aren't tacked directly onto the slave.jar itself. Still, I'd much prefer if the default jar cache was in the slave FS root. I have a number of slaves using an automounted home directory, and am hitting the quota exceeded error when upgrading from 1.544 to 1.551. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
