[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tuomas Kiviaho updated SUREFIRE-811: Attachment: ConsoleOutputCapture.patch I've been using the remoting approach by weawing an aspect ontop of "ForkedBooter" for a while now and the only thing that seems to be causing headache is capturing of the console output that is applied by surefire provider to both System out and err. Currently there is no logic preventing it from functioning in such threads that have not been inherited from the thread that turned on the capturing. This would not be a problem in normal style forking where every thread originated from ForkedBooter and System out is isolated by the process. In my case the ForkClient runs in same process and therefore uses the same System.out/err which are currently captured by surefire provider. Luckily this doesn't cause stack overflow, because ForkingRunListener - where the output ultimately ends up just - just encodes the output prior printing it out to the actual console. Here's a simple patch that fixed this issue for me. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > Attachments: ConsoleOutputCapture.patch > > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297755#comment-297755 ] Tuomas Kiviaho commented on SUREFIRE-811: - I've got quite similar requirements and for me it was sufficient to replace ForkedBooter with one that uses stub/skeleton pattern. Luckily I could use the local filesystem so it was only matter of using aspectj's weaver as java agent to avoid recompilation of surefire. I guess that this approach would have been sufficient because - if I understood the code correctly - there is an internal communication protocol that surefire uses to pass along test results and logging information. I guess it would be enough if ForkedBooter could be re-configured with a plugin dependency so that knowledge of runtime weaving would not be required. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293550#comment-293550 ] Henning Gross commented on SUREFIRE-811: We have decided not to write a patch for surefire as this would have meant to much effort / cost. Instead we have build a separate plugin to achieve our goals. It may be interesting for people coming here searching for a solution for a similar problem. You can find documentation, anonymous access to code and binaries/public maven repo here: https://evolvis.org/plugins/mediawiki/wiki/mvn-remote-test/index.php/Main_Page. If you want to add/change something, feel free to submit patches/join as a committer. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287260#comment-287260 ] Kristian Rosenvold commented on SUREFIRE-811: - Physically attached devices seems like a fairly good use case. You'll want to be looking at the "ForkStarter" class. The entire "response" part of the payload is serialized via the ForkClient so you might be able to make that work. I will review patches with testcases on this one; see maven-surefire-plugin/src/site/apt/developing.apt.vm (in the source checkout) on information about how to write these. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287248#comment-287248 ] Henning Gross commented on SUREFIRE-811: Well. In our case we have an onboard-unit. The target system has a variety of diffs to the build server. Jenkins is running on a 64 bit machine, the target system is 32 bit. This can be solved via maven but then again... the binary under test is not the one which gets released. Also we would need jenkins support firing some x as we want to test out SWT - Gui. Finally we interoperate with a lot of low-level stuff as dbus which requires native/system libs. Or even GPS, Cameras, devices connected via LIN-Bus. We could mock most of it but some automated real-life-tests would be good. Also some requirements to the build server would remain and this system is building a lot of projects which are supposed to be portable as our admins do not know about the specific per-project-requirements. We tend to rather make our projects build whereever and i do not see a better fit for integration-system-tests as the one suggested. Do you? I would appreciate your ideas... > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286692#comment-286692 ] Kristian Rosenvold commented on SUREFIRE-811: - We have previously marked similar issues as "wontFix". I am not flat our rejecting a patch, but I would be interested in hearing about the use cases for this one. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-811) remote-testing
Henning Gross created SUREFIRE-811: -- Summary: remote-testing Key: SUREFIRE-811 URL: https://jira.codehaus.org/browse/SUREFIRE-811 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin Reporter: Henning Gross Add the possibility to copy the target folder to remote machine and run integration-tests there. Copy back the results and handle them as if they would have been ran locally. I would volounteer to submit a patch for this feature if theres a chance it would be accepted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
