Re: POTD: Jenkinsfile Runner
Same exception here: java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; I created an issue with full stacktrace <https://github.com/kohsuke/jenkinsfile-runner/issues/7>. Jesse or Oleg, maybe you could elaborate there how we could fix this. Which Jar needs the manifest, which library needs to be whitelisted and how can we achieve this? Cheers, Johannes Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi: > > Jenkinsfile Runner is an experiment to package Jenkins pipeline execution > as a command line tool. The intend use cases include: > >- Use Jenkins in Function-as-a-Service context >- Assist editing Jenkinsfile locally >- Integration test shared libraries > > Over the past year, I've done some deep-dive 1:1 conversations with some > Jenkins users and I felt something like this might move the needle for them > in an important way. > > I'd love to hear any reactions on your side. Could something like this be > important for you, does it miss any key points for you? If you mentally > picture a perfect version of this, what would that do, and how would you > use? > > Let me know! > > -- > Kohsuke Kawaguchi > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/aef469a7-5b3f-4fb1-9ccf-12a11a3d1be5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: POTD: Jenkinsfile Runner
st approach was to build a Docker Image that contains
>> Jenkinsfile Runner and all default plugins.
>>
>> docker run -v~/src/it/myfunction:/workspace schnatterer/jenkinsfile-
>> runner:1.0-SNAPSHOT-2.108 /workspace
>>
>> runs the ~/foo/Jenkinsfile using Jenkinsfile Runner with all default
>> plugins of Jenkins 2.108.
>>
>> My idea was to eventually do the same in Jenkinsfile of the shared lib
>> like so (not tested)
>> docker.image('schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108').inside
>> {
>>
>> sh 'jenkinsfile-runner /app/jenkins /app/plugins src/it/myfunction'
>> }
>> or
>> sh 'docker run --rm -v $(pwd):$(pwd) src/it/myfunction'
>>
>
> So if this is the intended use case, then I have another idea. Instead of
> running Jenkinsfile in this CLI and try to emulate your Jenkins instance as
> closely as possible (in terms of configuration), we could just run
> Jenkinsfile in the current Jenkins, in a place that nobody else can see.
>
> For example, packaged as CLI, you'd run it like:
>
>$ java -jar jenkins-cli.jar -s https://jenkins.example.com/
> run-pipeline ./src/it/myfunction
>
> Or from within Jenkinsfile, could be something like:
>
> pipeline.sharedlibrary.test './src/it/myfunction'
>
> ... and this would completely bypass the challenge of trying to replicate
> the Jenkins configuration.
>
>
>
>> It turned out that there a two major problems:
>>
>>1. There's no way to add non-default Jenkins plugins.
>>My local test for cloudogu/ces-build-lib
>><https://github.com/cloudogu/ces-build-lib> failed because there was
>>no GitHub Groovy Libraries plugin.
>>Here, my hope is that Configuration-as-code plugin might help
>>automate loading plugins.
>>
>> Yeah, I'm really looking forward for CaC project to fill this gap, and I
> know they are working on it.
> <https://github.com/jenkinsci/jep/pull/59/files>
>
>>
>>1. There's still no way to load a "local" shared library from the
>>same repo. So, we still would have to find a way to configure the shared
>>library in our Jenkinsfile Runner.
>>Loading local shared libraries has already been discussed here
>><https://github.com/jenkinsci/workflow-cps-global-lib-plugin/pull/37>
>>and there <https://stackoverflow.com/q/46213913/1845976>.
>>
>> Good point.
>
>
>> Once those issues are solved, we'll have a very basic way of automating
>> integration tests for shared libraries by executing IT Jenkinsfiles from
>> the shared libraries pipeline and failing the build if the IT fails.
>>
>
> That'd be really cool, isn't it!?
>
>> Of course, this would be very basic testing. For more sophistiated
>> testing we would want to
>>
>>
>>- trigger the ITs from maven or gradle,
>>- use asserts,
>>- get the results as JUnit XML.
>>
>> So, yes, we're not there yet. But we now have a foundation to build all
>> this upon.
>>
>
> asserts would already work, right? It seems like we can do that relatively
> easily on its own.
>
> But with that aside, I think I understand the picture in your head. You
> are really approaching it like Maven plugin development. Indeed this would
> help illustrate relative strength of both JenkinsPipelineUnit and
> "integration tests"
>
>
>>
>> Thanks for that & best regards,
>>
>> Johannes
>>
>>
>> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>>
>>> Jenkinsfile Runner is an experiment to package Jenkins pipeline
>>> execution as a command line tool. The intend use cases include:
>>>
>>>- Use Jenkins in Function-as-a-Service context
>>>- Assist editing Jenkinsfile locally
>>>- Integration test shared libraries
>>>
>>> Over the past year, I've done some deep-dive 1:1 conversations with some
>>> Jenkins users and I felt something like this might move the needle for them
>>> in an important way.
>>>
>>> I'd love to hear any reactions on your side. Could something like this
>>> be important for you, does it miss any key points for you? If you mentally
>>> picture a perfect version of this, what would that do, and how would you
>>> use?
>>>
>>> Let me know!
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>>
>>
>> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>>
&
Re: POTD: Jenkinsfile Runner
I think Jenkinsfile Runner brings a lot of opportunities for pipeline
developers. The most obvious ones to me are
1. Pipeline development (Jenkinsfile)
2. Shared library development
*Pipeline development*
Right now (as described by others in this thread) pipeline development is
either a loop of committing / fixing pipelines on production Jenkins, using
pipeline replay on production Jenkins or setting up a local instance
manually.
With Jenkinsfile Runner we can get faster feedback without polluting our
commit or Jenkins build history and don't have to set up a local instance
manually.
*Shared library development*
Shared library development right now works much in the same as pipeline
development, except that you have the library code and another (often
production) Jenkinsfile to maintain, in order to try out (as opposed to
automatically test) your Jenkinsfile.
For shared libraries, we thankfully already have JenkinsPipelineUnit, that
makes it easier to implement some tests. However, (as also mentioned by
others in this thread) this is unit testing only. It mocks most of our
environment. Often, green unit tests mean nothing for productive use of our
share library. I even gave up test-driven development for shared libraries,
in favor of 90s try-and-error-style programming. Because most of the time
when trying the library with green unit tests in production, it turns out
that the real Jenkins environment has some restriction that is beyond the
scope of JenkinsPieplineUnit (e.g. sandboxing).
Worst thing about the current state is that we don't have reliable
regression tests. A change in shared library with green unit tests is far
from convincing me that the library will continue to work in production.
With Jenkinsfile Runner we could write small Jenkinsfiles within the shared
library repo's test folder and run them from the Jenkinsfile of the shared
lib. Pretty much in the same way as we use Maven Invoker Plugin (as
mentioned by Jesse) when developing maven plugins.
*A first approach to shared library integration testing with Jenkinsfile
Runner*
My naive first approach was to build a Docker Image that contains
Jenkinsfile Runner and all default plugins.
docker run -v~/src/it/myfunction:/workspace schnatterer/jenkinsfile-runner:
1.0-SNAPSHOT-2.108 /workspace
runs the ~/foo/Jenkinsfile using Jenkinsfile Runner with all default
plugins of Jenkins 2.108.
My idea was to eventually do the same in Jenkinsfile of the shared lib like
so (not tested)
docker.image('schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108').inside {
sh 'jenkinsfile-runner /app/jenkins /app/plugins src/it/myfunction'
}
or
sh 'docker run --rm -v $(pwd):$(pwd) src/it/myfunction'
It turned out that there a two major problems:
1. There's no way to add non-default Jenkins plugins.
My local test for cloudogu/ces-build-lib
<https://github.com/cloudogu/ces-build-lib> failed because there was no
GitHub Groovy Libraries plugin.
Here, my hope is that Configuration-as-code plugin might help automate
loading plugins.
2. There's still no way to load a "local" shared library from the same
repo. So, we still would have to find a way to configure the shared library
in our Jenkinsfile Runner.
Loading local shared libraries has already been discussed here
<https://github.com/jenkinsci/workflow-cps-global-lib-plugin/pull/37>
and there <https://stackoverflow.com/q/46213913/1845976>.
Once those issues are solved, we'll have a very basic way of automating
integration tests for shared libraries by executing IT Jenkinsfiles from
the shared libraries pipeline and failing the build if the IT fails.
Of course, this would be very basic testing. For more sophistiated testing
we would want to
- trigger the ITs from maven or gradle,
- use asserts,
- get the results as JUnit XML.
So, yes, we're not there yet. But we now have a foundation to build all
this upon.
Thanks for that & best regards,
Johannes
Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>
> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
> as a command line tool. The intend use cases include:
>
>- Use Jenkins in Function-as-a-Service context
>- Assist editing Jenkinsfile locally
>- Integration test shared libraries
>
> Over the past year, I've done some deep-dive 1:1 conversations with some
> Jenkins users and I felt something like this might move the needle for them
> in an important way.
>
> I'd love to hear any reactions on your side. Could something like this be
> important for you, does it miss any key points for you? If you mentally
> picture a perfect version of this, what would that do, and how would you
> use?
>
> Let me know!
>
> --
> Kohsuke Kawaguchi
>
Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Plugin hosting request, valgrind-plugin
hi, i wrote a jenkins plugin to run valgrind on executables and collect information about memory leaks and errors. Its in use for some of my other projects since a couple of weeks and i would like to share it with the jenkins community. github ID: eXistence github rep: git://github.com/eXistence/valgrind-plugin.git greetings, Johannes
Re: Plugin hosting request, valgrind-plugin
Hi Asmund, nice to hear there is some interest in a valgrind plugin. It just happened to require 1.455 because thats the version i am working and testing with, but as Ulli said its a really good idea to downgrade that to a LTS version of jenkins. I will do that, run some tests and make a new release (with some other small changes) over the course of the day. Johannes Am Mittwoch, 9. Mai 2012 09:44:02 UTC+2 schrieb asmundo: I have been hoping this should be created! On [1] it states that it needs Jenkins core 1.455 is this actually needed? I ask because my production environment is 1.445? I may consider upgrading Jenkins just because of this plugin, but I would prefer not to. Regards Asmund [1] https://wiki.jenkins-ci.org/display/JENKINS/Valgrind+Plugin On Fri, May 4, 2012 at 4:14 PM, Johannes Ohlemacher johannes.ohlemac...@googlemail.com wrote: hi, i wrote a jenkins plugin to run valgrind on executables and collect information about memory leaks and errors. Its in use for some of my other projects since a couple of weeks and i would like to share it with the jenkins community. github ID: eXistence github rep: git://github.com/eXistence/valgrind-plugin.git greetings, Johannes
kind and stapler-class attributes in JSON form data (since 1.463)
Hi everyone,
since version 1.463 i can't configure the Publisher of my plugin anymore.
The JSONObject form data contains two strange attributes: kind and
stapler-class. Because of those two attributes the StaplerRequest object
can't bind the form data to the data bound constructor of my configuration
class (or at least thats what i understand, i am still pretty new to
jenkins development...).
The JSONObject looks like this:
{failThresholdDefinitelyLost:,
failThresholdInvalidReadWrite:,
failThresholdTotal:,
kind:org.jenkinsci.plugins.valgrind.ValgrindPublisher,
pattern:*.memcheck,
stapler-class:org.jenkinsci.plugins.valgrind.ValgrindPublisher,
unstableThresholdDefinitelyLost:,
unstableThresholdInvalidReadWrite:,
unstableThresholdTotal:}
If i remove the two attributes from the JSONObject before binding it,
everything works fine...
publisher with descriptor (see lines 258 to 266):
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/java/org/jenkinsci/plugins/valgrind/ValgrindPublisher.java
configuration class:
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/java/org/jenkinsci/plugins/valgrind/config/ValgrindPublisherConfig.java
jelly file:
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/valgrind/ValgrindPublisher/config.jelly
Where do the kind and stapler-class attributes come from? They don't
appear with older versions of jenkins (i tested 1.455, 1.460 and 1.462).
Greetings,
Johannes
Re: kind and stapler-class attributes in JSON form data (since 1.463)
Hi Chris,
Thanks for your answer, that helped a lot :)
Regards,
Johannes
Am Montag, 14. Mai 2012 14:24:51 UTC+2 schrieb cjo:
Kind and stapler-class are used by the stapler to bind the configuration
section to the correct class (in this case your plugin), this also enabled
the stapler to use the Databound constructors of there objects rather than
the newInstance method of the descriptor.
From your code it looks like you don't have a data bound constructor for
ValgrindPublisher object.
Adding a Databound constructor, and removing the newInstance method from
the descriptor may fix the issue. However you may also need change the
config.jelly files so that ValgrindPublisherConfig has its own file.
Example constructor to add:
@DataBoundConstructor
public ValgrindPublisher (ValgrindPublisherConfig valgrindPublisherConfig){
this.valgrindPublisherConfig = valgrindpublisherconfig;
}
This change also makes the plugin work correctly with other plugins such
as the flexible publish and build condition where it is used as a sub
interface, these rely on having a correct DataBoundConstructor.
Chris
On Saturday, 12 May 2012 12:36:08 UTC+1, Johannes Ohlemacher wrote:
Hi everyone,
since version 1.463 i can't configure the Publisher of my plugin anymore.
The JSONObject form data contains two strange attributes: kind and
stapler-class. Because of those two attributes the StaplerRequest object
can't bind the form data to the data bound constructor of my configuration
class (or at least thats what i understand, i am still pretty new to
jenkins development...).
The JSONObject looks like this:
{failThresholdDefinitelyLost:,
failThresholdInvalidReadWrite:,
failThresholdTotal:,
kind:org.jenkinsci.plugins.valgrind.ValgrindPublisher,
pattern:*.memcheck,
stapler-class:org.jenkinsci.plugins.valgrind.ValgrindPublisher,
unstableThresholdDefinitelyLost:,
unstableThresholdInvalidReadWrite:,
unstableThresholdTotal:}
If i remove the two attributes from the JSONObject before binding it,
everything works fine...
publisher with descriptor (see lines 258 to 266):
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/java/org/jenkinsci/plugins/valgrind/ValgrindPublisher.java
configuration class:
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/java/org/jenkinsci/plugins/valgrind/config/ValgrindPublisherConfig.java
jelly file:
https://github.com/jenkinsci/valgrind-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/valgrind/ValgrindPublisher/config.jelly
Where do the kind and stapler-class attributes come from? They don't
appear with older versions of jenkins (i tested 1.455, 1.460 and 1.462).
Greetings,
Johannes
memory consumption of builds
Hello, i noticed a memory problem with my valgrind plugin for jenkins. The result of the valgrind plugin (basically a list of errors with stacktraces) is stored with the build (build.xml). After a fresh restart of jenkins, those builds gets deserialized and kept in memory as soon as the first user opens jenkins in his browser. Some users of my plugin have huge projects with a lot of errors (up to 1 per build). After a few dozen builds, all those errors and stacktraces are eating up a lot of memory, despite most of them are never needed. Why does jenkins always deserialize all builds for all jobs? My initial (naive?) expectation was that jenkins would only deserialize a build when a user opens it in the browser. Or am i doing something fundamentally wrong with the way the plugin stores its data? Regards, Johannes
FW: Unable to create bug reporting account
) at hudson.Proc$LocalProc.init(Proc.java:244) at hudson.Proc$LocalProc.init(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:773) at hudson.Launcher$ProcStarter.start(Launcher.java:353) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.tasks.Maven.perform(Maven.java:327) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1593) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) See also http://bugs.sun.com/view_bug.do?bug_id=8012453 To work around the issues immediately, the following two changes need to be done. 1) %base%\jenkins.xml a. Add -Djdk.lang.Process.allowAmbigousCommands to the arguments 2) In the configuration Manage Jenkins - Configure System - Maven Project Configuration a. Add -Djdk.lang.Process.allowAmbigousCommands to the Global MAVEN_OPTS Regards, Johannes -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Unable to create bug reporting account
(ProcessImpl.java:381) at java.lang.ProcessImpl.start(ProcessImpl.java:136) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1025) at hudson.Proc$LocalProc.init(Proc.java:244) at hudson.Proc$LocalProc.init(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:773) at hudson.Launcher$ProcStarter.start(Launcher.java:353) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.tasks.Maven.perform(Maven.java:327) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1593) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) See also http://bugs.sun.com/view_bug.do?bug_id=8012453 To work around the issues immediately, the following two changes need to be done. 1) %base%\jenkins.xml a. Add -Djdk.lang.Process.allowAmbigousCommands to the arguments 2) In the configuration Manage Jenkins - Configure System - Maven Project Configuration a. Add -Djdk.lang.Process.allowAmbigousCommands to the Global MAVEN_OPTS Regards, Johannes -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Own Cloud Plugin: "ClassNotFoundException: javax.servlet.ServletException" when running job for the first time
Hi Jesse, could you give me a hint how to try it out? I tried mvn hpi:run -Djenkins.version=2.154-rc27545.0e85c9fb206a which does not work (of course) because I don't have a snapshot repository configured. A quick search didn't give me the the URL for the snapshot repository. Could you help me out? Am Dienstag, 27. November 2018 16:58:26 UTC+1 schrieb Jesse Glick: > > it should deploy an incremental version > 2.154-rc27545.0e85c9fb206a which you can use as `jenkins.version` in > your POM (or passing via `-D` to `hpi:run`). > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e2ac800c-0ae7-4edb-9cfd-423c655ba605%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Own Cloud Plugin: "ClassNotFoundException: javax.servlet.ServletException" when running job for the first time
But where are the snapshots published to? I can't find the version 2.154-rc27545.0e85c9fb206a on https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-core/ I am running: mvn hpi:run -Djenkins.version=2.154-rc27545.0e85c9fb206a -Pconsume-incrementals Which does not work since https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-core/ doesn't contain that version. Am Donnerstag, 6. Dezember 2018 07:23:16 UTC+1 schrieb Baptiste Mathus: > > Note that the Incrementals repo is *not* configured behind > http://repo.jenkins-ci.org/public/ group repo on purpose. > So to enable automatic addition of that repository, you must add > -Pconsume-incrementals to your command line call, and hence use a recent > parent pom. See https://github.com/jenkinsci/plugin-pom > > I think some ~3.18+ should be enough, but I'd recommend updating to latest > 3.28 or 3.29 to avoid issues. > > Le mer. 5 déc. 2018 à 21:23, Daniel Beck > > a écrit : > >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bfaf26b7-6787-462d-8fd1-6e3567024938%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Own Cloud Plugin: "ClassNotFoundException: javax.servlet.ServletException" when running job for the first time
I will try > 2.154-rc27545.0e85c9fb206a > as soon as it is build. One question: What are the workarounds? What can be done? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3fce43eb-c21f-4adb-814e-c2b315cbc6e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Own Cloud Plugin: "ClassNotFoundException: javax.servlet.ServletException" when running job for the first time
:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) at java.lang.Thread.run(Thread.java:748) Caused: java.io.IOException: Remote call on JNLP4-connect connection from localhost/127.0.0.1:47026 failed at hudson.remoting.Channel.call(Channel.java:961) at hudson.Launcher$RemoteLauncher.kill(Launcher.java:1078) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:510) at hudson.model.Run.execute(Run.java:1798) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE ``` I tried to debug it further and could narrow it down. I think the exception is thrown the first time in the Method hudson.util.ProcessTree#get() (Line 399). Probably calling "SlaveComputer.getChannelToMaster()" fails. SlaveComputer references javax.servlet.ServletException which seems to be unavailable there. The agent.jar that is downloaded from Jenkins does *not* contain the javax.servlet.ServletException class. Running the job a second time on the same computer works just fine. The exception occurs after the job has finished. Any idea how to solve that? Regards, Johannes -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8feed20e-2416-4c05-b58d-15b4c3f7d56d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
