rfc: Solution for Sonar and Xvnc

[Rösch, Christian]

Hello.

tl;dr: Please have a look at https://github.com/croesch/xvnc-plugin/commit/55168876423efc3198993f692192a6b6bd56d55e and tell me if there's a better way to solve the problem.

We ran into a problem that seems to affect a couple of jenkins users that run xvnc and sonar. One of the earliest threads I found was this: http://sonarqube.15.x6.nabble.com/Sonar-plugin-fails-in-Jenkins-job-because-xvnc-is-terminated-too-early-tp4554438.html

In short, the problem is that sonar runs its analysis and therefore the tests AFTER the Xvnc plugin terminated the vncserver.

We discussed some solutions, namley

- run sonar as build step
- allow xvnc-plugin to be terminated after sonar action
- restart xvnc-plugin for sonar analysis
- somehow increase the opportunities by patching jenkins itself and adapting the two plugins afterwards
- some other dirty solutions

We decided to investigate in 'allow xvnc-plugin to be terminated after sonar action'. And we found a solution that is great in terms of solving our problem: We add an option that allows killing Xvnc as post build action. The xvnc-plugin creates an post build action (if the option is true) which kills the xvnc and appends it to the list of post build actions. The action also removes itself from the list after being executed to avoid persistency of our pseudo action.

The commit has been pushed here: https://github.com/croesch/xvnc-plugin/commit/55168876423efc3198993f692192a6b6bd56d55e

I know it does neither fulfil the code style, nor the test requirements, nor the commit message. But as it's a proof of concept, we wanted to publish the solution and have it discussed first before making it ready for being merged.

So I have a couple of questions

- Is this solution more or less stable as far as you can see?
- Could the problem be solved in a better way?
- If this is the best way, what needs to be done before filing a PR? Extend the tests of course, but shall I open an issue?

Thanks in advance!
-- Christian

[oliver gondža]

Hi,

Jenkins fails to serialize your anonymous Recorder implementation during
the build.

Xvfb plugin seems to have similar option addressing the problem with
RunListener[1] which is probably the best approach.

[1]
https://github.com/jenkinsci/xvfb-plugin/blob/master/src/main/java/org/jenkinsci/plugins/xvfb/XvfbBuildWrapper.java#L201

HTH
--
oliver

[Rösch, Christian]

Hi,

thanks for the quick reply and I'm sorry about the delay..

That seems to be a good approach. I'll try to do that with the Xvnc plugin but am not familiar enough to do that quickly. As e.g. Launcher can't be serialized I'm currently struggling to get that running with a RunListener.

But thank you very much :-)

-- Christian

________________________________________
From: oliver gondža [ogo...@gmail.com]
Sent: 08 June 2015 20:25
To: jenkin...@googlegroups.com; Rösch, Christian
Subject: Re: rfc: Solution for Sonar and Xvnc

[Jesse Glick]

On Mon, Jun 8, 2015 at 5:33 AM, Rösch, Christian
<Christia...@icongmbh.de> wrote:
> The xvnc-plugin creates an post build action (if the option is true) which kills the xvnc and appends it to the list of post build actions. The action also removes itself from the list after being executed to avoid persistency of our pseudo action.

Modifying project configuration from a build, even temporarily, is a bad idea.

> Could the problem be solved in a better way?

You can use the Xvnc build wrapper (1.22+) from a Workflow and
precisely control when the shutdown occurs. Sonar plugin compatibility
is probably still missing, but that is another matter.

Using a RunListener is also a hack IMO. If a solution is needed for
freestyle or Maven projects, it should be to run the tests as a build
step; for a publisher to run tests makes little sense.

[croesch]

Modifying project configuration from a build, even temporarily, is a bad idea.

I totally agree!
 

> Could the problem be solved in a better way?

You can use the Xvnc build wrapper (1.22+) from a Workflow and
precisely control when the shutdown occurs. Sonar plugin compatibility
is probably still missing, but that is another matter.

Using a RunListener is also a hack IMO. If a solution is needed for
freestyle or Maven projects, it should be to run the tests as a build
step; for a publisher to run tests makes little sense.

Do you refer to github:jenkinsci/workflow-plugin with "a Workflow"? I never used that.

But yes a solution is needed for maven projects and especially with sonar running the tests..

[croesch]

On Monday, 22 June 2015 21:28:12 UTC+2, Jesse Glick wrote:

If a solution is needed for
freestyle or Maven projects, it should be to run the tests as a build
step; for a publisher to run tests makes little sense.

Are you suggesting, that actually the way the sonar plugin works should be changed?

[Jesse Glick]

On Wed, Jul 8, 2015 at 10:51 AM, croesch <christia...@icongmbh.de> wrote:
> Are you suggesting, that actually the way the sonar plugin works should be changed?

From what little I know of that plugin, yes.