[JIRA] (JENKINS-48296) Multibranch pipeline - ignore commits from certain user
Title: Message Title James Johnson commented on JENKINS-48296 Re: Multibranch pipeline - ignore commits from certain user +1 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-48960) Org folders repository folder never runs scans on repository
Title: Message Title James Hardwick commented on JENKINS-48960 Re: Org folders repository folder never runs scans on repository Yea, we're in the same boat of keeping our Jenkins instance firewall'd off from the outside world, hence the polling. It's not a big deal for us since the Organization being polled has a fairly limited set of repos. Every company I've ever been with has used Jenkins this way, and usually has had very legitimate reasons for doing so. I think it'd be a mistake to have a default worldview of "webhooks everywhere". Just my $.02. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-48960) Org folders repository folder never runs scans on repository
Title: Message Title
James Hardwick edited a comment on JENKINS-48960
Re: Org folders repository folder never runs scans on repository
If it's any help, I had to setup a fresh Jenkins server for a new project. Again using GitHub Organization plugin to scan a repository for all available branches containing a Jenkinsfile. The repository scan worked the first time as expected, and then immediately started reproducing the original issue as described here. So, pretty easy to setup and reproduce as far as I can tell. I ended up just creating a job that contains [~tario]'s console script but instead as a pipeline script, so when the scan interval occasionally resets for whatever reason, I could just run the job and it's fixed. A la...{code:java}node { for (f in Jenkins.instance.getAllItems(jenkins.branch.MultiBranchProject.class)) {if (f.parent instanceof jenkins.branch.OrganizationFolder) { f.addTrigger(new com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger("5m"));} }}{code}[~stephenconnolly] I'm looking back and trying to understand your original request but not sure it makes sense. Can you break that down with a bit more detail as to just what exactly *should* be happening?
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
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] (JENKINS-48960) Org folders repository folder never runs scans on repository
Title: Message Title
James Hardwick commented on JENKINS-48960
Re: Org folders repository folder never runs scans on repository
If it's any help, I had to setup a fresh Jenkins server for a new project. Again using GitHub Organization plugin to scan a repository for all available branches containing a Jenkinsfile. The repository scan worked the first time as expected, and then immediately started reproducing the original issue as described here. So, pretty easy to setup and reproduce as far as I can tell. I ended up just creating a job that contains Patrick Ruckstuhl's console script but instead as a pipeline script, so when the scan interval occasionally resets for whatever reason, I could just run the job and it's fixed. A la...
node {
for (f in Jenkins.instance.getAllItems(jenkins.branch.MultiBranchProject.class)) {
if (f.parent instanceof jenkins.branch.OrganizationFolder) {
f.addTrigger(new com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger("5m"));
}
}
}
Stephen Connolly I'm looking back and trying to understand your original request but not sure it makes sense. Can you break that down with a bit more detail as to just what exactly should be happening?
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
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] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title hardwickj commented on JENKINS-41339 Re: Environment variables referencing other variables broken That doesn't actually fix it, it just spits out a warning regarding this issue and fails the job. 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] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title hardwickj commented on JENKINS-41339 Re: Environment variables referencing other variables broken It especially doesn't help when archives.jenkins-ci.org goes down and then you're just stuck. 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] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title hardwickj commented on JENKINS-41339 Re: Environment variables referencing other variables broken Part of the problem with the "downgrade" workaround is that if you've updated other plugins that depend on 1.13, those other plugins then do not get reloaded on restart, and therefore you cannot downgrade them in the plugin manager. Or am I missing something? 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] (JENKINS-41339) Environment variables referencing other variables broken
Title: Message Title hardwickj edited a comment on JENKINS-41339 Re: Environment variables referencing other variables broken Part of the problem with the "downgrade" workaround is that if you've updated other plugins that depend on durable-task: 1.13, those other plugins then do not get reloaded on restart, and therefore you cannot downgrade them in the plugin manager. Or am I missing something? 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] (JENKINS-32124) SCM Sync Configuration 0.0.9 causes empty Jenkins UI after install
Title: Message Title hardwickj commented on JENKINS-32124 Re: SCM Sync Configuration 0.0.9 causes empty Jenkins UI after install Frédéric Camblor I believe you only get the "downgrade to X.X.X" button if you previously had an old version installed. Thanks for the tip/link on installing the old version. That should suffice! I'll probably be installing this on a new 2+ version today or tomorrow and will report back how that goes... 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] (JENKINS-32124) SCM Sync Configuration 0.0.9 causes empty Jenkins UI after install
Title: Message Title hardwickj commented on JENKINS-32124 Re: SCM Sync Configuration 0.0.9 causes empty Jenkins UI after install Frédéric Camblor can we at least pull down the 0.0.9 version for the time being to help a lot of people avoid a major headache? We love the work you've done on this, and it's still useable via the previous release! 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] [workflow-plugin] (JENKINS-26912) 'build' workflow command ignores parameters, triggering default-only builds
James VL created JENKINS-26912 build workflow command ignores parameters, triggering default-only builds Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 11/Feb/15 11:55 PM Description: Summary It appears "Build a Job" in the Workflow DSL is not properly passing parameters to the jobs it builds. Sample Code build job: 'My Test Job', version: 'master' Where 'My Test Job' is normal Jenkins job. Expect to See Jenkins execute the job named 'My Test Job', setting its expected parameter named 'version' to the value 'master'. Actually See 'My Test Job' is run, but with whatever the default value is for 'version', not the value 'master'. Further notes: I tried various other formats of passing parameters to the build command (name, unnamed, key value list in a string...), but none worked. The snippet generator was not very helpful in trying to guess what to send. The Snippet Generator says of parameters: "parameters may be bound to a list of ParameterValues." and generates sample code: build 'My Test Job' I would welcome clarification in the snippet builder on how to use it with jobs that take parameters. It does not demonstrate or describe that the job name must be passed as the 'job' parameter. Environment: Jenkins 1.598 on Linux w/ Workflow 1.2 Project: Jenkins Priority: Major Reporter: James VL 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] [workflow-plugin] (JENKINS-26699) Workflow plugin silently breaks regular Groovy maps
James VL commented on JENKINS-26699 Workflow plugin silently breaks regular Groovy maps Thanks for taking the time to clarify this - I appreciate it. Didn't find the duplicate bug reort when I first searched. I wasn't sure if this feel under "fundamental limitation" or "CPS / Serialization bug". I've reverted to plain old loops in the mean time. 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] [workflow-plugin] (JENKINS-26699) Workflow plugin silently breaks regular Groovy maps
James VL commented on JENKINS-26699 Workflow plugin silently breaks regular Groovy maps I'm realizing that now, in trying to use lists in other places. If that was in the docs somewhere I totally missed it. Shall I assume that most groovy features which work with closures are not permitted in the workflow script then? 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] [copyartifact-plugin] (JENKINS-26694) Workflow build Parameters are not exposed to CopyArtifact
James VL created JENKINS-26694 Workflow build Parameters are not exposed to CopyArtifact Issue Type: Bug Assignee: Jesse Glick Components: copyartifact-plugin, workflow-plugin Created: 29/Jan/15 5:54 PM Description: If I use the CopyArtifact plugin with a workflow step(), it correctly pulls the latest successful build's artifacts when pointed to a project of type Workflow. However, if I specify parameters for that same project, it will always throw an AbortException saying no build with those parameters could be found, regardless of what I entered in. If I change the CopyArtifact to point to a freestyle project, the parameters correctly work as intended, pulling in most recent build that had those parameters. Since the CopyArtifact is behaving as it should, I'm assuming there's a flaw in how the Workflow plugin is exposing its build Parameters. Sample code: step ([$class: 'CopyArtifact', projectName: 'Test Run Composer', target: 'composer_run', parameters: "PRODUCT=test,BRANCH_NAME=$branch_name" ]); Environment: Jenkins 1.598 on Linux Workflow:Aggregator plugin 1.2 CopyArtifact plugin: 1.34 Project: Jenkins Labels: workflow-plugin copyartifact Priority: Minor Reporter: James VL 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] [workflow-plugin] (JENKINS-26699) Workflow plugin silently breaks regular Groovy maps
James VL
created JENKINS-26699
Workflow plugin silently breaks regular Groovy maps
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
30/Jan/15 12:23 AM
Description:
The docs mention the need for all data in steps to be serializable, but it doesn't mention that it somehow breaks Groovy maps in order to do.
If I run
def map = [foo: "bar", test: 'hello']
println 'Using Groovy version ' + GroovySystem.getVersion()
println map
map.each { k, v - println "$k := $v" }
I will see the following when I run groovy locally:
Using Groovy version 1.8.9
[foo:bar, test:hello]
foo := bar
test := hello
However, I'll get this output from the Jenkins workflow plugin: (note that the each() iteration only shows the first element, and it is not a key/value pair
Using Groovy version 1.8.9
Running: Print Message
{foo=bar, test=hello}
Running: Print Message
foo=bar := null
If this is expected behavior, it means users cannot use maps as expected, unless specifically passed to workflow classes that know how to read those parameters.
Am I doing something wrong here, or should the docs just be updated to reflect this?
Environment:
Jenkins 1.598
Workflow 1.2
Project:
Jenkins
Labels:
workflow
Priority:
Minor
Reporter:
James VL
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-10524) winstone.ClientSocketException: Failed to write to client
hardwickj
edited a comment on JENKINS-10524
winstone.ClientSocketException: Failed to write to client
If it were a matter of too many _javascript_ files being loaded than a lot more users would be having this problem.
If you guys are running Jenkins behind an apache proxy, try just hitting jenkins directly for a day and see what your results are. This might require typing a longer URL and appending :8080 at the end, but definitely worth it for debugging reasons.
All our problems went away once we figured out our apache proxying issue. We initially discovered the discrepancy by running the following curl command against jenkins, first through the apache proxy, and second against jenkins directly:
#!/bin/bash
for i in {1..100}
do
# via proxy
wget --quiet --spider http://build/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed via proxy"
fi
done
for i in {1..100}
do
# bypassing the proxy
wget --quiet --spider http://jenkins:8080/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed directly"
fi
done
If you run that and you only see "wget failed via proxy" but nothing directly, then it's your proxy configuration.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj
commented on JENKINS-10524
winstone.ClientSocketException: Failed to write to client
If it were a matter of too many _javascript_ files being loaded than a lot more users would be having this problem.
If you guys are running Jenkins behind an apache proxy, try just hitting jenkins directly for a day and see what your results are. This might require typing a longer URL and appending :8080 at the end, but definitely worth it for debugging reasons.
All our problems went away once we figured out our apache proxying issue. We initially discovered the discrepancy by running the following curl command against jenkins, first through the apache proxy, and second against jenkins directly:
{{
#!/bin/bash
for i in {1..100}
do
# via proxy
wget --quiet --spider http://build/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed via proxy"
fi
done
for i in {1..100}
do
bypassing the proxy
wget --quiet --spider http://jenkins:8080/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed directly"
fi
done
}}
If you run that and you only see "wget failed via proxy" but nothing directly, then it's your proxy configuration.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj
edited a comment on JENKINS-10524
winstone.ClientSocketException: Failed to write to client
If it were a matter of too many _javascript_ files being loaded than a lot more users would be having this problem.
If you guys are running Jenkins behind an apache proxy, try just hitting jenkins directly for a day and see what your results are. This might require typing a longer URL and appending :8080 at the end, but definitely worth it for debugging reasons.
All our problems went away once we figured out our apache proxying issue. We initially discovered the discrepancy by running the following curl command against jenkins, first through the apache proxy, and second against jenkins directly:
Unable to find source-code formatter for language: bash. Available languages are: _javascript_, sql, xhtml, actionscript, none, html, xml, java#!/bin/bash
for i in {1..100}
do
# via proxy
wget --quiet --spider http://build/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed via proxy"
fi
done
for i in {1..100}
do
# bypassing the proxy
wget --quiet --spider http://jenkins:8080/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed directly"
fi
done
If you run that and you only see "wget failed via proxy" but nothing directly, then it's your proxy configuration.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj
edited a comment on JENKINS-10524
winstone.ClientSocketException: Failed to write to client
If it were a matter of too many _javascript_ files being loaded than a lot more users would be having this problem.
If you guys are running Jenkins behind an apache proxy, try just hitting jenkins directly for a day and see what your results are. This might require typing a longer URL and appending :8080 at the end, but definitely worth it for debugging reasons.
All our problems went away once we figured out our apache proxying issue. We initially discovered the discrepancy by running the following curl command against jenkins, first through the apache proxy, and second against jenkins directly:
#!/bin/bash
for i in {1..100}
do
# via proxy
wget --quiet --spider http://build/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed via proxy"
fi
done
for i in {1..100}
do
# bypassing the proxy
wget --quiet --spider http://jenkins:8080/api/json?pretty=true
if [ $? -ne 0 ]; then
echo "wget failed directly"
fi
done
If you run that and you only see "wget failed via proxy" but nothing directly, then it's your proxy configuration.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj commented on JENKINS-10524 winstone.ClientSocketException: Failed to write to client My point being, if you use a proxy at all and are having issues, give that a try first. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hardwickj closed JENKINS-14825 as Duplicate winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 @xu, this issue was closed because it's a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-10524. Please post any comments or further information there instead. Re-closing... Change By: hardwickj (15/May/13 3:13 PM) Status: Reopened Closed Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj commented on JENKINS-10524 winstone.ClientSocketException: Failed to write to client I've been trying to find a pattern as well for reproducing this (and JENKINS-14825) but have had no luck. The randomness is making it a really stickler. I'll keep trying and hopefully we can come up with something. Thanks for looking into it Jesse! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-10524) winstone.ClientSocketException: Failed to write to client
hardwickj commented on JENKINS-10524 winstone.ClientSocketException: Failed to write to client @Kohsuke I also suspected the monitoring plugin, so I uninstalled it entirely and removed JENKINS_HOME/monitoring. Still no luck. The odd thing about this is that it seems to result in HTTP 404 errors on the front end, sometimes for an entire page and other times just for certain ajax calls. I'd expect a 500ish error. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hardwickj updated JENKINS-14825 winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 Change By: hardwickj (06/May/13 2:57 PM) Priority: Major Critical This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hardwickj commented on JENKINS-14825 winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 We've been seeing this occasionally, and cannot nail it down to a root cause. I've disabled numerous plugins to try and narrow it down, but I'm still unable to find anything that can recreate it consistently. The error seems to result in parts of the web app returning 404. Must be some of the ajax'y portions that make a call out after the initial page load. Unfortunately we also make fairly heavy use of Jenkins API's, and with the API randomly returning a 404 it's severely impacting our workflow. It seems odd to me that the API/UI return a 404 error when in the log we're seeing a straight up exception. I'd expect some sort of 500 error... This is what we see in our logs: May 06, 2013 10:55:13 AM org.kohsuke.stapler.compression.CompressionFilter reportException WARNING: Untrapped servlet exception javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/ssd/hudson/war/WEB-INF/lib/jenkins-core-1.514.jar!/lib/hudson/summary.jelly:49:48: j:when Failed to write to client at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:117) ... Caused by: org.apache.commons.jelly.JellyTagException: jar:file:/ssd/hudson/war/WEB-INF/lib/jenkins-core-1.514.jar!/lib/hudson/summary.jelly:49:48: j:when Failed to write to client at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:726) ... Caused by: winstone.ClientSocketException: Failed to write to client at winstone.ClientOutputStream.write(ClientOutputStream.java:41) ... Caused by: java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15303) Building grails with Jenkins is causing an exception during runtime.
hardwickj commented on JENKINS-15303 Building grails with Jenkins is causing an exception during runtime. For starters, you are using invalid syntax for your hasMany map in DomainOne. I'd fix that first and then probably close this bug. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15303) Building grails with Jenkins is causing an exception during runtime.
hardwickj updated JENKINS-15303 Building grails with Jenkins is causing an exception during runtime. Change By: hardwickj (27/Mar/13 3:09 PM) Priority: Critical Trivial This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15303) Building grails with Jenkins is causing an exception during runtime.
hardwickj commented on JENKINS-15303 Building grails with Jenkins is causing an exception during runtime. You still have invalid syntax. "mapping" is supposed to be a closure, but you are defining it sort of like a map (See http://grails.org/doc/latest/guide/single.html#ormdsl) Please attach a complete zipped app containing this example that shows this working correctly. I have a hard time believing it would work correctly anywhere, let alone Jenkins. The jenkins grails plugin isn't going to alter the runtime GORM mapping behavior of grails. The only way it could do so is if you supplied an external config as part of the build step, which is a standard Grails convention anyways and again nothing specific to Jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-14345) Grails wrapper doesn't respect Project Base Directory
hardwickj commented on JENKINS-14345 Grails wrapper doesnt respect Project Base Directory From what I can tell it broke the use of all variables inside every one of the individual setting fields. A work around is to set all properties in the "Properties" box, which for whatever reason does seem to still be working. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13549) Duplicate test results are shown for grails projects
hardwickj resolved JENKINS-13549 as Not A Defect Duplicate test results are shown for grails projects Resolving since it's not a bug, but rather an improperly defined pattern that matched multiple duplicate results Change By: hardwickj (27/Mar/13 4:54 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/groups/opt_out.
[JIRA] (JENKINS-15812) JAVA_HOME is superseded by the JVM used to start the jenkins slave
hardwickj commented on JENKINS-15812 JAVA_HOME is superseded by the JVM used to start the jenkins slave I'm also seeing this. The systems running our slaves have JAVA_HOME defined globally for all users to a default version of the JDK. Jenkins has multiple JDK's defined in "Manage Jenkins - Configure System - JDK's". Despite setting a specific version of a JDK for a given job, JAVA_HOME is still that which was used when starting Jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15812) JAVA_HOME is superseded by the JVM used to start the jenkins slave
hardwickj updated JENKINS-15812 JAVA_HOME is superseded by the JVM used to start the jenkins slave Change By: hardwickj (27/Mar/13 9:54 PM) Priority: Major Critical This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15812) JAVA_HOME is superseded by the JVM used to start the jenkins slave
hardwickj commented on JENKINS-15812 JAVA_HOME is superseded by the JVM used to start the jenkins slave Yea, I added an "echo $JAVA_HOME" shell build step to verify. When running the job, this is what I see in the logs which confirms my fears: Building remotely on build03 in workspace /data/tomcat/jenkins/workspace/Build-master Unpacking http://macallan/sources/java/jdk-6u43-linux-x64.tar.gz to /data/tomcat/jenkins/tools/hudson.model.JDK/JDK_6u39 on build03 ... Build-master $ /bin/sh -xe /data/tomcat/jenkins/tmp/hudson2047019797614409905.sh + echo /usr/java/default /usr/java/default The "/usr/java/default" being the default value for $JAVA_HOME on the OS. So even though it's retrieving the correct JDK and extracting it, it's not setting JAVA_HOME to it. The kicker is that if we don't have a default JAVA_HOME set on the host OS, then the "Default" JDK in Jenkins also never has a JAVA_HOME. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15812) JAVA_HOME is superseded by the JVM used to start the jenkins slave
hardwickj updated JENKINS-15812 JAVA_HOME is superseded by the JVM used to start the jenkins slave Change By: hardwickj (27/Mar/13 10:06 PM) Priority: Critical Blocker This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15812) JAVA_HOME is superseded by the JVM used to start the jenkins slave
hardwickj commented on JENKINS-15812 JAVA_HOME is superseded by the JVM used to start the jenkins slave Oh, and we are seeing this on CentOS host OS's running our Jenkins slaves. Doesn't appear to be a windows only 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/groups/opt_out.
[JIRA] (JENKINS-7750) Grails Plugin - You can't use build.job.name=${env['JOB_NAME']} in the 'properties' box.
hardwickj
commented on JENKINS-7750
Grails Plugin - You cant use build.job.name=${env[JOB_NAME]} in the properties box.
nudge. We hit this today as well. Tried using $WORKSPACE to define the grails.work.dir. No go. Had to downgrade to 1.5 as well to get all the standard Jenkins env variables back. This to me seems like a blocker.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-7750) Grails Plugin - You can't use build.job.name=${env['JOB_NAME']} in the 'properties' box.
hardwickj
updated JENKINS-7750
Grails Plugin - You cant use build.job.name=${env[JOB_NAME]} in the properties box.
Change By:
hardwickj
(30/Jan/13 3:54 AM)
Priority:
Major
Critical
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.
