Re: Unable to anonymously clone a Jenkins scriptler repository
As a followup - anonymous cloning works as expected with the following environment: CentOS 6.7 64 bit Tomcat 7.0.69 (ASF) JRE 1.7.0_80 (Oracle - sigh) Apache HTTPD 2.2.15-47 mod_jk 1.2.41 (ASF) git 1.7.1 Jenkins 1.656 Scriptler 2.9 So I'm missing something in my upgrade from 1.656 to 2.x? Mark /mde/ On Wednesday, May 25, 2016 at 1:56:07 PM UTC-7, Mark Eggers wrote: > > Hi, > > I'm trying to reorganize a bunch of Groovy scripts with Scriptler, and I > would like to use the git repository. > > My environment: > > CentOS 6.8 64 bit > JRE 1.8.0_92 (Oracle) > git 1.7.12.4 (rpmforge) > > Apache HTTPD 2.2.15-53 (CentOS) > mod_jk 1.2.41 (ASF) > Tomcat 8.0.33 (ASF) > > Jenkins 2.6 (upgraded from the last 1.6x release) > scriptler 2.9 > git 2.4.4 > git-client 1.19.6 > git-server 1.6 > > From the documentation, it indicates that I should be able to clone the > git repository of scriptler from http://[jenkins-url]/scriptler.git > > However, if I try to clone this from Windows 7 64 bit (git > 2.6.3.windows.1), I get the following: > > Cloning into 'scriptler'... > error: fatal: RPC failed; result=22, HTTP code = 403 > The remote end hung up unexpectedly > > I've tried this both through HTTPD and through Tomcat directly (port 8080). > > I understand that to push to the git repository, I'll have to have > credentials. However, I'm not able to clone the existing repository, whether > it's empty or it contains a sample script. > > Obviously I am doing something wrong. What do I need to do to make this > work? > > Mark > /mde/ > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/682b8802-f7a9-4779-9c28-182b105f422e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Unable to anonymously clone a Jenkins scriptler repository
Hi, I'm trying to reorganize a bunch of Groovy scripts with Scriptler, and I would like to use the git repository. My environment: CentOS 6.8 64 bit JRE 1.8.0_92 (Oracle) git 1.7.12.4 (rpmforge) Apache HTTPD 2.2.15-53 (CentOS) mod_jk 1.2.41 (ASF) Tomcat 8.0.33 (ASF) Jenkins 2.6 (upgraded from the last 1.6x release) scriptler 2.9 git 2.4.4 git-client 1.19.6 git-server 1.6 >From the documentation, it indicates that I should be able to clone the git repository of scriptler from http://[jenkins-url]/scriptler.git However, if I try to clone this from Windows 7 64 bit (git 2.6.3.windows.1), I get the following: Cloning into 'scriptler'... error: fatal: RPC failed; result=22, HTTP code = 403 The remote end hung up unexpectedly I've tried this both through HTTPD and through Tomcat directly (port 8080). I understand that to push to the git repository, I'll have to have credentials. However, I'm not able to clone the existing repository, whether it's empty or it contains a sample script. Obviously I am doing something wrong. What do I need to do to make this work? Mark /mde/ -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0a886a98-2a6f-42d5-b9e0-bccc01f6309f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins default update center
No, I removed it via Manage UpdateSites. Oddly enough, just disabling it did not actually disable it. The update site was still checked as evidenced by the time stamp on the file in $JENKINS_HOME/updates. /mde/ On Monday, April 11, 2016 at 4:40:06 PM UTC-7, Daniel Beck wrote: > > > On 12.04.2016, at 01:09, Mark Eggers <mdeg...@gmail.com > > wrote: > > > If I remove the third party update center on the test Jenkins, then > Jenkins acts as if there are no update sites available. > > If by that you mean that you clear the form field in Manage Plugins » > Advanced, don't do that. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b8f6eb25-6ffa-4a7f-aeee-488e22ce02b6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Jenkins default update center
I thought that I had two identical Jenkins 1.656 installations (production and test), running on Tomcat 7.0.68. However on the test system I'm not able to get updates from the default update center (a third party update center works). When I look at the logs of the failing system, there is no line with: Obtained the latest update center data file for UpdateSource default The hudson.model.UpdateCenter.xml files are identical If I remove the third party update center on the test Jenkins, then Jenkins acts as if there are no update sites available. I would appreciate any insights. If worse comes to worse, I could rebuild the test environment as long as I can recover the jobs, workspaces, and tasks. Thanks for any ideas. Mark /mde/ -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/52413f11-19ab-4929-9878-bf9d38606377%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Reverse Proxy Broken (mod_jk)
I get the 404, but I don't get any errors on the management pages. I don't think that referring to mod_jk as a proxy is strictly correct. See the following for a detailed explanation. http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html As an aside - mod_proxy_ajp is basically mod_jk. It's just that the configuration is different (both use AJP/1.3 under the covers). You may run into some problems if you're serving Jenkins from differing contexts. For example: 1. Web server - http://hostname/ -- gets to Jenkins 2. Tomcat - http://hostname:8080/jenkins/ -- gets to Jenkins In those cases you'll probably have to do some rewriting. I haven't done extensive Jenkins programming, so I don't know if my setup breaks for any of the use cases mentioned here: https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML I've also not trolled through all the pages to see if the Location header is being rewritten properly (no port 8080). However, I suspect that it is since the site works. The only issue I'm observing is that pages representing modules in multi-module builds aren't being rendered correctly in Chrome. Much of the formatting and hyperlinks are missing. However, the same pages render correctly in Firefox. I suspect it's a Chrome vs. Jenkins issue. . . . . just my two cents /mde/ On Thursday, March 12, 2015 at 2:00:28 AM UTC-7, Marcos Rey wrote: Forgot to append the output: HTTP/1.1 302 Found Date: Thu, 12 Mar 2015 08:57:51 GMT Server: Apache/2.2.15 (CentOS) Cache-Control: private Expires: Thu, 01 Jan 1970 01:00:00 CET Location: https://hostname/jenkins/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/testForReverseProxySetup/https%3A%2F%2Fhostname%2Fjenkins%2Fmanage/ Content-Length: 0 Connection: close Content-Type: text/plain; charset=UTF-8 HTTP/1.1 404 Not Found Date: Thu, 12 Mar 2015 08:57:52 GMT Server: Apache/2.2.15 (CentOS) Content-Length: 442 Connection: close Content-Type: text/html; charset=iso-8859-1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title404 Not Found/title /headbody h1Not Found/h1 pThe requested URL /jenkins/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/testForReverseProxySetup/ https://hostname/jenkins/manage/ was not found on this server./p hr addressApache/2.2.15 (CentOS) Server at hostname Port 443/address /body/html El jueves, 12 de marzo de 2015, 9:55:59 (UTC+1), Marcos Rey escribió: You are totally right, my bad. If I try the curl test, I get a 404 (as expected). El jueves, 12 de marzo de 2015, 9:47:08 (UTC+1), Daniel Beck escribió: That's why the curl command specifies a referer, something you don't have if you just open that URL. On 12.03.2015, at 09:16, Marcos Rey sole...@gmail.com wrote: If it helps, if i manually try the url: https://hostname/jenkins/manage https://hostname/jenkins/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/test, tomcat returns this: HTTP 404 - https://hostname/jenkins/manage vs. NO-REFERER El jueves, 12 de marzo de 2015, 9:14:49 (UTC+1), Marcos Rey escribió: Thanks Rui, i would consider mod_ajp. The weird thing is that i have a similar production deployment that does not have this issue. Mark, thanks for sharing your config, mine is quite similar, but I still get the proxy reverse broken error. The weird thing is that everything seems to be working fine, so I might skip this for the meanwhile. Also, could you please verify that your installation passes the 'curl' test? curl -iL -e https://hostname/jenkins/manage https://hostname/jenkins/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/test Also, I'm using https... I'm not sure if that's what's causing the issue. Thanks both for your help and for taking your time to answer. El jueves, 12 de marzo de 2015, 0:54:57 (UTC+1), Mark Eggers escribió: I've not seen this. For my Jenkins URL: http://[hostname]/jenkins/ In my uriworker.properties file: /jenkins|/*=[workername] Then in the Apache HTTPD host that manages Jenkins: JkMountFile conf.d/uriworkermap.properties There's a good base workers.properties configuration example in conf subdirectory of the mod_jk source code. I'm running 1.602 on CentOS 6.6, Apache HTTPD 2.2.15-39, mo_jk 1.40, Tomcat 7.0.57, and Oracle JRE 1.7.0_76 64 bit. I'm using the APR connector (Tomcat native compiled and in Java library path). All my connectors are set to UTF-8. . . . just my two cents /mde/ On Wednesday, March 11, 2015 at 2:25:13 PM UTC-7, Rui Fernando Hayashi wrote: I've managed to solve that using mod_proxy_ajp. On Wed, Mar 11, 2015 at 7:37 AM, Marcos Rey sole...@gmail.com wrote: Hello! I've been reading the messages around the list and I see that more people see this message on 'Manage Jenkins' when running apache+mod_jk with Jenkins
Re: Reverse Proxy Broken (mod_jk)
I've not seen this. For my Jenkins URL: http://[hostname]/jenkins/ In my uriworker.properties file: /jenkins|/*=[workername] Then in the Apache HTTPD host that manages Jenkins: JkMountFile conf.d/uriworkermap.properties There's a good base workers.properties configuration example in conf subdirectory of the mod_jk source code. I'm running 1.602 on CentOS 6.6, Apache HTTPD 2.2.15-39, mo_jk 1.40, Tomcat 7.0.57, and Oracle JRE 1.7.0_76 64 bit. I'm using the APR connector (Tomcat native compiled and in Java library path). All my connectors are set to UTF-8. . . . just my two cents /mde/ On Wednesday, March 11, 2015 at 2:25:13 PM UTC-7, Rui Fernando Hayashi wrote: I've managed to solve that using mod_proxy_ajp. On Wed, Mar 11, 2015 at 7:37 AM, Marcos Rey sole...@gmail.com javascript: wrote: Hello! I've been reading the messages around the list and I see that more people see this message on 'Manage Jenkins' when running apache+mod_jk with Jenkins. Any input would be greatly appreciated. Regards, -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c66b22b3-b92b-440b-be5c-97be4e2e2d40%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-users/c66b22b3-b92b-440b-be5c-97be4e2e2d40%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0f0bab7f-19fd-4577-9bd0-2f30c7da697d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Warning: Problems with Jenkins 1.600 when env-inject is installed
Not at this time. I'll wait to see when jobs are triggered by an SCM checkin. A quick check with a deploy job which uses BUILD_ID showed no issues. I just read the notice on the matrix project plugin page to not install that version. With the patch that addressed JENKINS-27188 https://issues.jenkins-ci.org/browse/JENKINS-27188, is that warning no longer valid? Thanks for the quick response (sorry for the 'cc - didn't see the checkbox on google groups). /mde/ On Wednesday, March 4, 2015 at 8:16:46 AM UTC-8, Daniel Beck wrote: 1.4.1 is bundled with Jenkins 1.600+. Are you experiencing any problems? Because it's only incompatible with earlier Jenkins versions. On 04.03.2015, at 17:09, Mark Eggers mdeg...@gmail.com javascript: wrote: I just rolled out 1.601 on two machines. It appears that the matrix project plugin version 1.4.1 is back. On one machine I attempted to both unpin and roll back the plugin version to 1.3. After a restart the plugin version remains at 1.4.1. I now no longer have the option of downgrading the plugin. I've tried reinstalling 1.601, with no success. Any thoughts on how to recover from this? On Tuesday, March 3, 2015 at 10:43:06 PM UTC-8, Daniel Beck wrote: 1.601 has been released out of cycle and fixes these issues. Changelog: http://jenkins-ci.org/changelog JENKINS-27178, 27188, and 27199 are the same bug and not listed separately. On 02.03.2015, at 14:19, Daniel Beck m...@beckweb.net wrote: There are a few issues with Jenkins 1.600 when the popular env-inject plugin is installed. More information is available in Jira: https://issues.jenkins-ci.org/browse/JENKINS-27178 https://issues.jenkins-ci.org/browse/JENKINS-27188 The first issue doesn't really look like an issue with Jenkins (and the second isn't as noticeable), so I thought I'd notify this list about them. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/bcb96ef6-de85-4f3c-af29-d54ed8b73113%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/485dc6d7-755f-451b-9c45-25751950c459%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.598 Maven builds failing StackOverflowError
I am seeing this as well. However, one Jenkins server works flawlessly, while the other one does not. The only difference is that the impacted server is using subversion 1.8, while the operational server is using subversion 1.6. There are some other issues as well - I'll try to document them when I get some clear steps to reproduce them. Mark /mde/ On Tue, 27 Jan 2015 19:35:17 +, Jeff wrote: After upgrading to 1.598, all of my Maven builds broke as well but I am unable to even build. (We pull from Nexus) I downgraded to 1.597 and it is working again (so far). The console output has this: [workspace] $ /usr/local/bin/p4 -s sync -f //jenkins_core/...@693973 Sync complete, took 4580 ms Parsing POMs using settings config with name my-settings.xml FATAL: nulljava.lang.StackOverflowError http://stacktrace.jenkins-ci.org/search? query=java.lang.StackOverflowError at sun.reflect.GeneratedMethodAccessor328.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.google.inject.internal.DelegatingInvocationHandler.invoke (DelegatingInvocationHandler.java:40) at com.sun.proxy.$Proxy66.lookup(Unknown Source) at sun.reflect.GeneratedMethodAccessor328.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.google.inject.internal.DelegatingInvocationHandler.invoke (DelegatingInvocationHandler.java:40) ... at com.sun.proxy.$Proxy66.lookup(Unknown Source) at sun.reflect.GeneratedMethodAccessor328.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.google.inject.internal.DelegatingInvocationHandler.invoke (DelegatingInvocationHandler.java:40) at com.sun.proxy.$Proxy66.lookup(Unknown Source) at sun.reflect.GeneratedMethodAccessor328.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.google.inject.internal.DelegatingInvocationHandler.invoke (DelegatingInvocationHandler.java:40) End of Console On Tue Jan 27 2015 at 4:38:31 AM James Green james.mk.gr...@gmail.com wrote: With 1.598 we're seeing StackOverflowErrors on deploying to Nexus. On downgrading to 1.597 our builds are fixed. These issues appear relevant, worthwhile mentioning to the wider community here: https://issues.jenkins-ci.org/browse/JENKINS-26601 https://issues.jenkins-ci.org/browse/JENKINS-26595 James -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/ ez6zc...@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAMH6%2Bax1L% 2BqniFkcvsymmuaQPot%3Danx9iTU%3DnZ7aQYg19UcnZw%40mail.gmail.com https://groups.google.com/d/msgid/jenkinsci-users/CAMH6%2Bax1L% 2BqniFkcvsymmuaQPot%3Danx9iTU%3DnZ7aQYg19UcnZw%40mail.gmail.com? utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/majcvq%24t61%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: mod_jk v proxying
On Friday, December 19, 2014 8:55:43 AM UTC-8, MoBarger wrote: Hi - working on implementing the latest LTS update, we are encountering the reverse proxy error when going to Jenkins admin page. Is it possible to resolve this issue using mod_jk configuration we currently use or is the only option to move to a proxy server setup? I am not finding much in terms of solutions in my searches. Thanks. I don't know what issue you're having (we run leading edge, not LTS). That being said, our set up is as follows: 1. Apache HTTPD on CentOS 6.6 (2.2.15-39) 2. mod_jk 1.2.40 3. Tomcat 7.0.57 4. JRE 1.7.0_72 We use a uriworkermap.properties file with: /jenkins|/*=[worker-name] Seems to work fine. We can reach the admin page with no problem, the REST API works as expected, and interaction with the Nexus server running on a different host (same architecture as above, /nexus|/*=[worker-name]) works as expected. I've long been a fan of mod_jk since I'm not as fluent in the rewrite rules necessary to make proxy configurations work all of the time. . . . just my two cents */mde/* -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d5b0ec41-ac47-4e3a-931b-43dbd8ab046e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to get the artefacts version number into the email notification subject line?
To expand on what Bertram wrote:
It appears that the Jenkins Maven release plugin sets a few parameters:
MVN_RELEASE_VERSION
MVN_DEV_VERSION
MVN_ISDRYRUN
I've not tried this, but it may be possible to use this information coupled
with the
email extension plugin to send the appropriate message. Borrowing from the
following:
http://stackoverflow.com/questions/16685052/how-to-send-an-email-from-jenkins-only-in-a-release
you might be able to send email only when a release occurs as well.
I think you would reference the parameters in your message (or title) as:
${ENV.VAR=MVN_RELEASE_VERSION}
I haven't tried this yet - it's on my list of things to do this weekend.
. . . just my two cents
/mde/
On Sat, 16 Aug 2014 01:34:52 -0700, Bertram Karch wrote:
Hi,
I have not tested this, but I think you can do this with the envinject
plugin and the extended email notification plugin.
Set the version number with envinject in an environment variable and use
this environment variable in the email subject.
Regards,
Bertram
Am Freitag, 15. August 2014 13:51:26 UTC+2 schrieb andreas...@gmail.com:
Hi,
we build releases with the maven release plugin. We want the subject line
to include the version number. Because it changes during the process i want
to get the version number out of the artifacts (this is easy) and now i
want the version number in the subject line of the mail. Does anybody has
an idea?
Regards,
Andreas
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Deploying versioned WAR to Tomcat 7
This appears to be the following issue:
https://issues.jenkins-ci.org/browse/JENKINS-19564
My initial take on this is that it's a Cargo issue with parallel deployment.
Mark
/mde/
On Monday, August 4, 2014 6:23:40 PM UTC-7, Mark Eggers wrote:
Further followup:
It seems that the Deploy plugin doesn't work well with versioned WAR files
(ConsumeIt##nnn.war). The first deploy works as expected, and the second
deploy (with an incrementally increased BUILD_NUMBER) fails with:
Deploying
/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war
to container Tomcat 7.x Remote
Redeploying
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
Undeploying
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to
exception
org.codehaus.cargo.container.ContainerException
http://stacktrace.jenkins-ci.org/search?query=org.codehaus.cargo.container.ContainerException:
Failed to
undeploy
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
This is understandable, since there is no ConsumeIt##15.war. There was a
ConsumeIt##13.war (running), and a ConsumeIt##14.war (failed to deploy with
the same message as above).
Undeploying ConsumeIt##13.war from the command line with:
curl --anyauth -u redacted:redacted '
http://thor.mdeggers.org:8080/manager/text/undeploy?path=/ConsumeItversion=13
'
works as expected, and then the next Jenkins deployment works as well.
Maybe this is an enhancement request?
Mark
/mde/
On Monday, August 4, 2014 5:21:18 PM UTC-7, Mark Eggers wrote:
Never mind, I figured it out. It turns out that the deploy URL in the
configuration needs to be the base URL (http://thor.mdeggers.org:8080),
and NOT the manager URL (http://thor.mdeggers.org:8080/manager/text).
Now I have to figure out how to filter context.xml so that I can run the
application in NetBeans, and still have versioned applications on Tomcat.
However, that's a Maven question.
Sorry for the noise.
Mark
/mde/
On Monday, August 4, 2014 4:55:25 PM UTC-7, Mark Eggers wrote:
Hi,
I'm trying to use the deploy plugin to deploy to a Tomcat 7.0.55 server.
I'm trying to use versioned WAR files (appName##number.war).
I can create the WAR file easily by passing BUILD_NUMBER in on the
command line
and then using a property within finalName.
The first problem came when specifying the WAR file for the deploy
plugin. Using
appName##${BUILD_NUMBER}.war caused the underlying ant task to fail.
I solved that by using **/*.war.
Now Jenkins finds and attempts to deploy the WAR file only to get:
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to
exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy
[/home/tcadmin/.jenkins/jobs/appName-Deploy/workspace/target/appName##9.war]
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:189)
at
hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:922)
at hudson.FilePath.act(FilePath.java:895)
at
hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at
hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at
hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736)
at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685)
at hudson.model.Run.execute(Run.java:1757)
at
hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by:
org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL -
Unknown command /manager/text/list
I can successfully do an http://thor.mdeggers.org:8080/manager/text/list
from the command line
using curl with the same authentication parameters.
$ curl --anyauth -u redacted:redacted
http://thor.mdeggers.org:8080/manager/text/list
OK - Listed applications for virtual host thor
/:running:0:ROOT
/manager:running:4:/home/tcadmin
Deploying versioned WAR to Tomcat 7
Hi,
I'm trying to use the deploy plugin to deploy to a Tomcat 7.0.55 server.
I'm trying to use versioned WAR files (appName##number.war).
I can create the WAR file easily by passing BUILD_NUMBER in on the command line
and then using a property within finalName.
The first problem came when specifying the WAR file for the deploy plugin. Using
appName##${BUILD_NUMBER}.war caused the underlying ant task to fail.
I solved that by using **/*.war.
Now Jenkins finds and attempts to deploy the WAR file only to get:
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy
[/home/tcadmin/.jenkins/jobs/appName-Deploy/workspace/target/appName##9.war]
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:189)
at
hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:922)
at hudson.FilePath.act(FilePath.java:895)
at
hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at
hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736)
at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685)
at hudson.model.Run.execute(Run.java:1757)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException:
FAIL - Unknown command /manager/text/list
I can successfully do an http://thor.mdeggers.org:8080/manager/text/list from
the command line
using curl with the same authentication parameters.
$ curl --anyauth -u redacted:redacted
http://thor.mdeggers.org:8080/manager/text/list
OK - Listed applications for virtual host thor
/:running:0:ROOT
/manager:running:4:/home/tcadmin/Apache/apache-tomcat-7.0.55/webapps/manager
/LeakRS:running:0:LeakRS
/probe:running:0:probe
/JSPSamples:running:0:JSPSamples
/nexus:running:0:nexus
/calcs:running:0:calcs
What am I doing wrong?
Mark
/mde/
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Deploying versioned WAR to Tomcat 7
Never mind, I figured it out. It turns out that the deploy URL in the
configuration needs to be the base URL (http://thor.mdeggers.org:8080), and
NOT the manager URL (http://thor.mdeggers.org:8080/manager/text).
Now I have to figure out how to filter context.xml so that I can run the
application in NetBeans, and still have versioned applications on Tomcat.
However, that's a Maven question.
Sorry for the noise.
Mark
/mde/
On Monday, August 4, 2014 4:55:25 PM UTC-7, Mark Eggers wrote:
Hi,
I'm trying to use the deploy plugin to deploy to a Tomcat 7.0.55 server.
I'm trying to use versioned WAR files (appName##number.war).
I can create the WAR file easily by passing BUILD_NUMBER in on the command
line
and then using a property within finalName.
The first problem came when specifying the WAR file for the deploy plugin.
Using
appName##${BUILD_NUMBER}.war caused the underlying ant task to fail.
I solved that by using **/*.war.
Now Jenkins finds and attempts to deploy the WAR file only to get:
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to
exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy
[/home/tcadmin/.jenkins/jobs/appName-Deploy/workspace/target/appName##9.war]
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:189)
at
hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:922)
at hudson.FilePath.act(FilePath.java:895)
at
hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at
hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at
hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736)
at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685)
at hudson.model.Run.execute(Run.java:1757)
at
hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by:
org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL -
Unknown command /manager/text/list
I can successfully do an http://thor.mdeggers.org:8080/manager/text/list
from the command line
using curl with the same authentication parameters.
$ curl --anyauth -u redacted:redacted
http://thor.mdeggers.org:8080/manager/text/list
OK - Listed applications for virtual host thor
/:running:0:ROOT
/manager:running:4:/home/tcadmin/Apache/apache-tomcat-7.0.55/webapps/manager
/LeakRS:running:0:LeakRS
/probe:running:0:probe
/JSPSamples:running:0:JSPSamples
/nexus:running:0:nexus
/calcs:running:0:calcs
What am I doing wrong?
Mark
/mde/
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Deploying versioned WAR to Tomcat 7
Further followup:
It seems that the Deploy plugin doesn't work well with versioned WAR files
(ConsumeIt##nnn.war). The first deploy works as expected, and the second
deploy (with an incrementally increased BUILD_NUMBER) fails with:
Deploying
/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war
to container Tomcat 7.x Remote
Redeploying
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
Undeploying
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException
http://stacktrace.jenkins-ci.org/search?query=org.codehaus.cargo.container.ContainerException:
Failed to
undeploy
[/home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##15.war]
This is understandable, since there is no ConsumeIt##15.war. There was a
ConsumeIt##13.war (running), and a ConsumeIt##14.war (failed to deploy with
the same message as above).
Undeploying ConsumeIt##13.war from the command line with:
curl --anyauth -u redacted:redacted
'http://thor.mdeggers.org:8080/manager/text/undeploy?path=/ConsumeItversion=13'
works as expected, and then the next Jenkins deployment works as well.
Maybe this is an enhancement request?
Mark
/mde/
On Monday, August 4, 2014 5:21:18 PM UTC-7, Mark Eggers wrote:
Never mind, I figured it out. It turns out that the deploy URL in the
configuration needs to be the base URL (http://thor.mdeggers.org:8080),
and NOT the manager URL (http://thor.mdeggers.org:8080/manager/text).
Now I have to figure out how to filter context.xml so that I can run the
application in NetBeans, and still have versioned applications on Tomcat.
However, that's a Maven question.
Sorry for the noise.
Mark
/mde/
On Monday, August 4, 2014 4:55:25 PM UTC-7, Mark Eggers wrote:
Hi,
I'm trying to use the deploy plugin to deploy to a Tomcat 7.0.55 server.
I'm trying to use versioned WAR files (appName##number.war).
I can create the WAR file easily by passing BUILD_NUMBER in on the
command line
and then using a property within finalName.
The first problem came when specifying the WAR file for the deploy
plugin. Using
appName##${BUILD_NUMBER}.war caused the underlying ant task to fail.
I solved that by using **/*.war.
Now Jenkins finds and attempts to deploy the WAR file only to get:
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to
exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy
[/home/tcadmin/.jenkins/jobs/appName-Deploy/workspace/target/appName##9.war]
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:189)
at
hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at
hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:922)
at hudson.FilePath.act(FilePath.java:895)
at
hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at
hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at
hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736)
at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685)
at hudson.model.Run.execute(Run.java:1757)
at
hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by:
org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL -
Unknown command /manager/text/list
I can successfully do an http://thor.mdeggers.org:8080/manager/text/list
from the command line
using curl with the same authentication parameters.
$ curl --anyauth -u redacted:redacted
http://thor.mdeggers.org:8080/manager/text/list
OK - Listed applications for virtual host thor
/:running:0:ROOT
/manager:running:4:/home/tcadmin/Apache/apache-tomcat-7.0.55/webapps/manager
/LeakRS:running:0:LeakRS
/probe:running:0:probe
/JSPSamples:running:0:JSPSamples
/nexus:running:0:nexus
/calcs:running:0:calcs
What am I doing wrong?
Mark
/mde/
--
You received this message because you are subscribed
