Jenkins › Jenkins users

hudson as a Win7 service + xUnit/cppUnit

Classic

List

Threaded

9 messages Options

Joris Koster-2

hudson as a Win7 service + xUnit/cppUnit

We’re running Hudson on x64 Win7 machine. We used to login into the ‘builder’ account on that machine and start through the JNLP agent (via IE). Unfortunately each time when the machine reboots we need to go through that cycle again, so I opted for installing it as service instead (log in as admin and start through JNLP à install as service).

This however caused the cppunit/xunit plugin to fail (I’m not sure which version we were running; let’s say some version from May):

Archiving artifacts

[xUnit] Starting to record.

ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted due to exception

hudson.util.IOException2: The plugin hasn't been performed correctly.

at com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)

...

at hudson.model.Executor.run(Executor.java:124)

Caused by: hudson.util.IOException2: remote file operation failed: c:\hudson\workspace\Windows32Debug at [hidden email]

...

Finished: FAILURE

I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit 1.6) and set "Fail the build if test results were not updated this run" = True:

Archiving artifacts

[xUnit] Starting to record.

[xUnit] Can't create the path /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory already exists.

[xUnit] The plugin hasn't been performed correctly: remote file operation failed: c:/hudson/workspace/Windows32Debug at hudson.remoting.Channel@2110ba:Oberon

Finished: FAILURE

Next I decided to revert to running from the user account instead of as-a-service:

Archiving artifacts

[xUnit] Starting to record.

[xUnit] Can't create the path /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory already exists.

[xUnit] [CppUnit-1.x] - Processing 1 files with the pattern 'trunk/build/output/win32/debug/unit*.xml' relative to 'c:\hudson\workspace\Windows32Debug'.

[xUnit] [INFO] - Converting 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml' .

[xUnit] [WARNING] - Can't delete the file: c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml

[xUnit] Stopping recording.

Finished: SUCCESS

I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same result; I’ve tried running the service on the builder account à same result (as service).

Next I tried comparing the environment (‘System Information’) between running as service and as user, and there are a lot of differences… I think there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and a run-as-service with correct or incorrect, but different results.

Fortunately we can just continue on our old scheme (login into the builder account and start through JNLP manually) since that will just report the builds succeeded (and failed when actually a unit-test or compile failed).

We would like to run as service however, so maybe I’m missing some settings to accomplish this, any clues/ideas would be welcome.

Kind regards,
Joris Koster

Senior Software Developer

Paragon Decision Technology

www.aimms.com

CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

Kent Larsson-3

Re: hudson as a Win7 service + xUnit/cppUnit

Hi!

We are experiencing the exact same issue, but with Windows Server
2008. I hope it will be fixed soon, should we file a bug report?

Thank you for telling the world about the workaround, it will surely be useful!

On Mon, Jul 26, 2010 at 12:01, Joris Koster <[hidden email]> wrote:

> Hi
>
>
>
> We’re running Hudson on x64 Win7 machine. We used to login into the
> ‘builder’ account on that machine and start through the JNLP agent (via IE).
> Unfortunately each time when the machine reboots we need to go through that
> cycle again, so I opted for installing it as service instead (log in as
> admin and start through JNLP à install as service).
>
>
>
> This however caused the cppunit/xunit plugin to fail (I’m not sure which
> version we were running; let’s say some version from May):
>
>
>
> Archiving artifacts
>
> [xUnit] Starting to record.
>
> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
> due to exception
>
> hudson.util.IOException2: The plugin hasn't been performed correctly.
>
>       at
> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>
>     ...
>
>       at hudson.model.Executor.run(Executor.java:124)
>
> Caused by: hudson.util.IOException2: remote file operation failed:
> c:\hudson\workspace\Windows32Debug at
> hudson.remoting.Channel@127d3b74:Oberon
>
>      ...
>
> Finished: FAILURE
>
>
>
> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
> 1.6) and set "Fail the build if test results were not updated this run" =
> True:
>
>
>
> Archiving artifacts
>
> [xUnit] Starting to record.
>
> [xUnit] Can't create the path
> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
> already exists.
>
> [xUnit] The plugin hasn't been performed correctly: remote file operation
> failed: c:/hudson/workspace/Windows32Debug at
> hudson.remoting.Channel@2110ba:Oberon
>
> Finished: FAILURE
>
>
>
> Next I decided to revert to running from the user account instead of
> as-a-service:
>
> Archiving artifacts
>
> [xUnit] Starting to record.
>
> [xUnit] Can't create the path
> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
> already exists.
>
> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
> 'trunk/build/output/win32/debug/unit*.xml' relative to
> 'c:\hudson\workspace\Windows32Debug'.
>
> [xUnit] [INFO] - Converting
> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
> .
>
> [xUnit] [WARNING] - Can't delete the file:
> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>
> [xUnit] Stopping recording.
>
> Finished: SUCCESS
>
>
>
> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
> result; I’ve tried running the service on the builder account à same result
> (as service).
>
> Next I tried comparing the environment (‘System Information’) between
> running as service and as user, and there are a lot of differences… I think
> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
> a run-as-service with correct or incorrect, but different results.
>
>
>
> Fortunately we can just continue on our old scheme (login into the builder
> account and start through JNLP manually) since that will just report the
> builds succeeded (and failed when actually a unit-test or compile failed).
>
>
>
> We would like to run as service however, so maybe I’m missing some settings
> to accomplish this, any clues/ideas would be welcome.
>
>
>
> Kind regards,
> Joris Koster
>
> Senior Software Developer
>
> Paragon Decision Technology
>
> www.aimms.com
>
>
>
>
>
>
>
> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
> privileged. If you are not a named recipient, please notify the sender
> immediately and do not disclose the contents to another person, use it for
> any purpose or store or copy the information in any medium.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gregory Boissinot

Re: hudson as a Win7 service + xUnit/cppUnit

In reply to this post by Joris Koster-2

Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?

2010/7/26 Joris Koster <[hidden email]>:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Kent Larsson

Re: hudson as a Win7 service + xUnit/cppUnit

In reply to this post by Joris Koster-2

Hi,

Thank you for answering! I'll do my best to describe our experience
with the problem.

I upgraded to 1.7 today. Unfortunately we still experience the same problem.

We have the dotnet job running on a Windows slave running Windows
Server 2008, our master is running Ubuntu.

The plugins we use: http://i.imgur.com/m0rFx.png

This is how our job configuration looks: http://i.imgur.com/St2zu.png

And this is the console output for that job: http://i.imgur.com/ZogTg.png

As you can see from the console output (the xUnit output is last) the
path seems a bit strange.

Best regards,
Kent Larsson

2010/8/27 Grégory Boissinot <[hidden email]>:

> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>
> 2010/7/26 Joris Koster <[hidden email]>:
>> Hi
>>
>>
>>
>> We’re running Hudson on x64 Win7 machine. We used to login into the
>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>> Unfortunately each time when the machine reboots we need to go through that
>> cycle again, so I opted for installing it as service instead (log in as
>> admin and start through JNLP à install as service).
>>
>>
>>
>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>> version we were running; let’s say some version from May):
>>
>>
>>
>> Archiving artifacts
>>
>> [xUnit] Starting to record.
>>
>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>> due to exception
>>
>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>
>> at
>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>
>> ...
>>
>> at hudson.model.Executor.run(Executor.java:124)
>>
>> Caused by: hudson.util.IOException2: remote file operation failed:
>> c:\hudson\workspace\Windows32Debug at
>> hudson.remoting.Channel@127d3b74:Oberon
>>
>> ...
>>
>> Finished: FAILURE
>>
>>
>>
>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>> 1.6) and set "Fail the build if test results were not updated this run" =
>> True:
>>
>>
>>
>> Archiving artifacts
>>
>> [xUnit] Starting to record.
>>
>> [xUnit] Can't create the path
>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>> already exists.
>>
>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>> failed: c:/hudson/workspace/Windows32Debug at
>> hudson.remoting.Channel@2110ba:Oberon
>>
>> Finished: FAILURE
>>
>>
>>
>> Next I decided to revert to running from the user account instead of
>> as-a-service:
>>
>> Archiving artifacts
>>
>> [xUnit] Starting to record.
>>
>> [xUnit] Can't create the path
>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>> already exists.
>>
>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>> 'c:\hudson\workspace\Windows32Debug'.
>>
>> [xUnit] [INFO] - Converting
>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>> .
>>
>> [xUnit] [WARNING] - Can't delete the file:
>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>
>> [xUnit] Stopping recording.
>>
>> Finished: SUCCESS
>>
>>
>>
>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>> result; I’ve tried running the service on the builder account à same result
>> (as service).
>>
>> Next I tried comparing the environment (‘System Information’) between
>> running as service and as user, and there are a lot of differences… I think
>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>> a run-as-service with correct or incorrect, but different results.
>>
>>
>>
>> Fortunately we can just continue on our old scheme (login into the builder
>> account and start through JNLP manually) since that will just report the
>> builds succeeded (and failed when actually a unit-test or compile failed).
>>
>>
>>
>> We would like to run as service however, so maybe I’m missing some settings
>> to accomplish this, any clues/ideas would be welcome.
>>
>>
>>
>> Kind regards,
>> Joris Koster
>>
>> Senior Software Developer
>>
>> Paragon Decision Technology
>>
>> www.aimms.com
>>
>>
>>
>>
>>
>>
>>
>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>> privileged. If you are not a named recipient, please notify the sender
>> immediately and do not disclose the contents to another person, use it for
>> any purpose or store or copy the information in any medium.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gregory Boissinot

Re: hudson as a Win7 service + xUnit/cppUnit

Regarding the log, the execution is correct.
The warning with the message 'Can't create the path' is due the fact
that the directory already exists:
- It has not be deleted the previous run
- The option 'Delete generated output' is unchecked.

Have you got any comments?

2010/8/27 Kent Larsson <[hidden email]>:

> Hi,
>
> Thank you for answering! I'll do my best to describe our experience
> with the problem.
>
> I upgraded to 1.7 today. Unfortunately we still experience the same problem.
>
> We have the dotnet job running on a Windows slave running Windows
> Server 2008, our master is running Ubuntu.
>
> The plugins we use: http://i.imgur.com/m0rFx.png
>
> This is how our job configuration looks: http://i.imgur.com/St2zu.png
>
> And this is the console output for that job: http://i.imgur.com/ZogTg.png
>
> As you can see from the console output (the xUnit output is last) the
> path seems a bit strange.
>
> Best regards,
> Kent Larsson
>
> 2010/8/27 Grégory Boissinot <[hidden email]>:
>> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>>
>> 2010/7/26 Joris Koster <[hidden email]>:
>>> Hi
>>>
>>>
>>>
>>> We’re running Hudson on x64 Win7 machine. We used to login into the
>>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>>> Unfortunately each time when the machine reboots we need to go through that
>>> cycle again, so I opted for installing it as service instead (log in as
>>> admin and start through JNLP à install as service).
>>>
>>>
>>>
>>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>>> version we were running; let’s say some version from May):
>>>
>>>
>>>
>>> Archiving artifacts
>>>
>>> [xUnit] Starting to record.
>>>
>>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>>> due to exception
>>>
>>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>>
>>> at
>>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>>
>>> ...
>>>
>>> at hudson.model.Executor.run(Executor.java:124)
>>>
>>> Caused by: hudson.util.IOException2: remote file operation failed:
>>> c:\hudson\workspace\Windows32Debug at
>>> hudson.remoting.Channel@127d3b74:Oberon
>>>
>>> ...
>>>
>>> Finished: FAILURE
>>>
>>>
>>>
>>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>>> 1.6) and set "Fail the build if test results were not updated this run" =
>>> True:
>>>
>>>
>>>
>>> Archiving artifacts
>>>
>>> [xUnit] Starting to record.
>>>
>>> [xUnit] Can't create the path
>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>> already exists.
>>>
>>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>>> failed: c:/hudson/workspace/Windows32Debug at
>>> hudson.remoting.Channel@2110ba:Oberon
>>>
>>> Finished: FAILURE
>>>
>>>
>>>
>>> Next I decided to revert to running from the user account instead of
>>> as-a-service:
>>>
>>> Archiving artifacts
>>>
>>> [xUnit] Starting to record.
>>>
>>> [xUnit] Can't create the path
>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>> already exists.
>>>
>>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>>> 'c:\hudson\workspace\Windows32Debug'.
>>>
>>> [xUnit] [INFO] - Converting
>>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>>> .
>>>
>>> [xUnit] [WARNING] - Can't delete the file:
>>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>>
>>> [xUnit] Stopping recording.
>>>
>>> Finished: SUCCESS
>>>
>>>
>>>
>>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>>> result; I’ve tried running the service on the builder account à same result
>>> (as service).
>>>
>>> Next I tried comparing the environment (‘System Information’) between
>>> running as service and as user, and there are a lot of differences… I think
>>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>>> a run-as-service with correct or incorrect, but different results.
>>>
>>>
>>>
>>> Fortunately we can just continue on our old scheme (login into the builder
>>> account and start through JNLP manually) since that will just report the
>>> builds succeeded (and failed when actually a unit-test or compile failed).
>>>
>>>
>>>
>>> We would like to run as service however, so maybe I’m missing some settings
>>> to accomplish this, any clues/ideas would be welcome.
>>>
>>>
>>>
>>> Kind regards,
>>> Joris Koster
>>>
>>> Senior Software Developer
>>>
>>> Paragon Decision Technology
>>>
>>> www.aimms.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>>> privileged. If you are not a named recipient, please notify the sender
>>> immediately and do not disclose the contents to another person, use it for
>>> any purpose or store or copy the information in any medium.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Kent Larsson

Re: hudson as a Win7 service + xUnit/cppUnit

Yes. Unfortunately it doesn't matter if I have it checked or not. If I
make sure to delete it manually and make 100% certain that it is gone,
the error is still there.

Kent Larsson
Utvecklare

Euroling AB
Igeldammsgatan 22C
112 49 Stockholm
08-519 00 522 (direkt)
08-519 00 500 (växel)

Euroling SiteSeeker - Sökning och analys för webbplatser och intranät

2010/8/28 Grégory Boissinot <[hidden email]>:

> Regarding the log, the execution is correct.
> The warning with the message 'Can't create the path' is due the fact
> that the directory already exists:
> - It has not be deleted the previous run
> - The option 'Delete generated output' is unchecked.
>
> Have you got any comments?
>
> 2010/8/27 Kent Larsson <[hidden email]>:
>> Hi,
>>
>> Thank you for answering! I'll do my best to describe our experience
>> with the problem.
>>
>> I upgraded to 1.7 today. Unfortunately we still experience the same problem.
>>
>> We have the dotnet job running on a Windows slave running Windows
>> Server 2008, our master is running Ubuntu.
>>
>> The plugins we use: http://i.imgur.com/m0rFx.png
>>
>> This is how our job configuration looks: http://i.imgur.com/St2zu.png
>>
>> And this is the console output for that job: http://i.imgur.com/ZogTg.png
>>
>> As you can see from the console output (the xUnit output is last) the
>> path seems a bit strange.
>>
>> Best regards,
>> Kent Larsson
>>
>> 2010/8/27 Grégory Boissinot <[hidden email]>:
>>> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>>>
>>> 2010/7/26 Joris Koster <[hidden email]>:
>>>> Hi
>>>>
>>>>
>>>>
>>>> We’re running Hudson on x64 Win7 machine. We used to login into the
>>>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>>>> Unfortunately each time when the machine reboots we need to go through that
>>>> cycle again, so I opted for installing it as service instead (log in as
>>>> admin and start through JNLP à install as service).
>>>>
>>>>
>>>>
>>>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>>>> version we were running; let’s say some version from May):
>>>>
>>>>
>>>>
>>>> Archiving artifacts
>>>>
>>>> [xUnit] Starting to record.
>>>>
>>>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>>>> due to exception
>>>>
>>>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>>>
>>>> at
>>>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>>>
>>>> ...
>>>>
>>>> at hudson.model.Executor.run(Executor.java:124)
>>>>
>>>> Caused by: hudson.util.IOException2: remote file operation failed:
>>>> c:\hudson\workspace\Windows32Debug at
>>>> hudson.remoting.Channel@127d3b74:Oberon
>>>>
>>>> ...
>>>>
>>>> Finished: FAILURE
>>>>
>>>>
>>>>
>>>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>>>> 1.6) and set "Fail the build if test results were not updated this run" =
>>>> True:
>>>>
>>>>
>>>>
>>>> Archiving artifacts
>>>>
>>>> [xUnit] Starting to record.
>>>>
>>>> [xUnit] Can't create the path
>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>> already exists.
>>>>
>>>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>>>> failed: c:/hudson/workspace/Windows32Debug at
>>>> hudson.remoting.Channel@2110ba:Oberon
>>>>
>>>> Finished: FAILURE
>>>>
>>>>
>>>>
>>>> Next I decided to revert to running from the user account instead of
>>>> as-a-service:
>>>>
>>>> Archiving artifacts
>>>>
>>>> [xUnit] Starting to record.
>>>>
>>>> [xUnit] Can't create the path
>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>> already exists.
>>>>
>>>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>>>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>>>> 'c:\hudson\workspace\Windows32Debug'.
>>>>
>>>> [xUnit] [INFO] - Converting
>>>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>>>> .
>>>>
>>>> [xUnit] [WARNING] - Can't delete the file:
>>>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>>>
>>>> [xUnit] Stopping recording.
>>>>
>>>> Finished: SUCCESS
>>>>
>>>>
>>>>
>>>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>>>> result; I’ve tried running the service on the builder account à same result
>>>> (as service).
>>>>
>>>> Next I tried comparing the environment (‘System Information’) between
>>>> running as service and as user, and there are a lot of differences… I think
>>>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>>>> a run-as-service with correct or incorrect, but different results.
>>>>
>>>>
>>>>
>>>> Fortunately we can just continue on our old scheme (login into the builder
>>>> account and start through JNLP manually) since that will just report the
>>>> builds succeeded (and failed when actually a unit-test or compile failed).
>>>>
>>>>
>>>>
>>>> We would like to run as service however, so maybe I’m missing some settings
>>>> to accomplish this, any clues/ideas would be welcome.
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>> Joris Koster
>>>>
>>>> Senior Software Developer
>>>>
>>>> Paragon Decision Technology
>>>>
>>>> www.aimms.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>>>> privileged. If you are not a named recipient, please notify the sender
>>>> immediately and do not disclose the contents to another person, use it for
>>>> any purpose or store or copy the information in any medium.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Kent Larsson

Re: hudson as a Win7 service + xUnit/cppUnit

Hi again!

I double checked as I can't trust myself! ;-) But it seems I were
correct, I now have this configuration http://i.imgur.com/QsrIG.png
and this console output http://i.imgur.com/LsIJh.png . Do you have an
idea on what it could be? If I can help in any way I am more than
willing to do so! :-)

Kent Larsson
Utvecklare

Euroling AB
Igeldammsgatan 22C
112 49 Stockholm
08-519 00 522 (direkt)
08-519 00 500 (växel)

Euroling SiteSeeker - Sökning och analys för webbplatser och intranät

On Mon, Aug 30, 2010 at 8:27 AM, Kent Larsson <[hidden email]> wrote:

> Yes. Unfortunately it doesn't matter if I have it checked or not. If I
> make sure to delete it manually and make 100% certain that it is gone,
> the error is still there.
>
> Kent Larsson
> Utvecklare
>
> Euroling AB
> Igeldammsgatan 22C
> 112 49 Stockholm
> 08-519 00 522 (direkt)
> 08-519 00 500 (växel)
>
> Euroling SiteSeeker - Sökning och analys för webbplatser och intranät
>
>
>
> 2010/8/28 Grégory Boissinot <[hidden email]>:
>> Regarding the log, the execution is correct.
>> The warning with the message 'Can't create the path' is due the fact
>> that the directory already exists:
>> - It has not be deleted the previous run
>> - The option 'Delete generated output' is unchecked.
>>
>> Have you got any comments?
>>
>> 2010/8/27 Kent Larsson <[hidden email]>:
>>> Hi,
>>>
>>> Thank you for answering! I'll do my best to describe our experience
>>> with the problem.
>>>
>>> I upgraded to 1.7 today. Unfortunately we still experience the same problem.
>>>
>>> We have the dotnet job running on a Windows slave running Windows
>>> Server 2008, our master is running Ubuntu.
>>>
>>> The plugins we use: http://i.imgur.com/m0rFx.png
>>>
>>> This is how our job configuration looks: http://i.imgur.com/St2zu.png
>>>
>>> And this is the console output for that job: http://i.imgur.com/ZogTg.png
>>>
>>> As you can see from the console output (the xUnit output is last) the
>>> path seems a bit strange.
>>>
>>> Best regards,
>>> Kent Larsson
>>>
>>> 2010/8/27 Grégory Boissinot <[hidden email]>:
>>>> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>>>>
>>>> 2010/7/26 Joris Koster <[hidden email]>:
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> We’re running Hudson on x64 Win7 machine. We used to login into the
>>>>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>>>>> Unfortunately each time when the machine reboots we need to go through that
>>>>> cycle again, so I opted for installing it as service instead (log in as
>>>>> admin and start through JNLP à install as service).
>>>>>
>>>>>
>>>>>
>>>>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>>>>> version we were running; let’s say some version from May):
>>>>>
>>>>>
>>>>>
>>>>> Archiving artifacts
>>>>>
>>>>> [xUnit] Starting to record.
>>>>>
>>>>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>>>>> due to exception
>>>>>
>>>>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>>>>
>>>>> at
>>>>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>>>>
>>>>> ...
>>>>>
>>>>> at hudson.model.Executor.run(Executor.java:124)
>>>>>
>>>>> Caused by: hudson.util.IOException2: remote file operation failed:
>>>>> c:\hudson\workspace\Windows32Debug at
>>>>> hudson.remoting.Channel@127d3b74:Oberon
>>>>>
>>>>> ...
>>>>>
>>>>> Finished: FAILURE
>>>>>
>>>>>
>>>>>
>>>>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>>>>> 1.6) and set "Fail the build if test results were not updated this run" =
>>>>> True:
>>>>>
>>>>>
>>>>>
>>>>> Archiving artifacts
>>>>>
>>>>> [xUnit] Starting to record.
>>>>>
>>>>> [xUnit] Can't create the path
>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>> already exists.
>>>>>
>>>>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>>>>> failed: c:/hudson/workspace/Windows32Debug at
>>>>> hudson.remoting.Channel@2110ba:Oberon
>>>>>
>>>>> Finished: FAILURE
>>>>>
>>>>>
>>>>>
>>>>> Next I decided to revert to running from the user account instead of
>>>>> as-a-service:
>>>>>
>>>>> Archiving artifacts
>>>>>
>>>>> [xUnit] Starting to record.
>>>>>
>>>>> [xUnit] Can't create the path
>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>> already exists.
>>>>>
>>>>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>>>>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>>>>> 'c:\hudson\workspace\Windows32Debug'.
>>>>>
>>>>> [xUnit] [INFO] - Converting
>>>>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>>>>> .
>>>>>
>>>>> [xUnit] [WARNING] - Can't delete the file:
>>>>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>>>>
>>>>> [xUnit] Stopping recording.
>>>>>
>>>>> Finished: SUCCESS
>>>>>
>>>>>
>>>>>
>>>>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>>>>> result; I’ve tried running the service on the builder account à same result
>>>>> (as service).
>>>>>
>>>>> Next I tried comparing the environment (‘System Information’) between
>>>>> running as service and as user, and there are a lot of differences… I think
>>>>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>>>>> a run-as-service with correct or incorrect, but different results.
>>>>>
>>>>>
>>>>>
>>>>> Fortunately we can just continue on our old scheme (login into the builder
>>>>> account and start through JNLP manually) since that will just report the
>>>>> builds succeeded (and failed when actually a unit-test or compile failed).
>>>>>
>>>>>
>>>>>
>>>>> We would like to run as service however, so maybe I’m missing some settings
>>>>> to accomplish this, any clues/ideas would be welcome.
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> Joris Koster
>>>>>
>>>>> Senior Software Developer
>>>>>
>>>>> Paragon Decision Technology
>>>>>
>>>>> www.aimms.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>>>>> privileged. If you are not a named recipient, please notify the sender
>>>>> immediately and do not disclose the contents to another person, use it for
>>>>> any purpose or store or copy the information in any medium.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Kent Larsson

Re: hudson as a Win7 service + xUnit/cppUnit

Hi again,

I created a bug report for this issue:
http://hudson.361315.n4.nabble.com/hudson-as-a-Win7-service-xUnit-cppUnit-td2302125.html#a2302125

Best regards,
Kent Larsson

On Mon, Aug 30, 2010 at 9:28 AM, Kent Larsson <[hidden email]> wrote:

> Hi again!
>
> I double checked as I can't trust myself! ;-) But it seems I were
> correct, I now have this configuration http://i.imgur.com/QsrIG.png
> and this console output http://i.imgur.com/LsIJh.png . Do you have an
> idea on what it could be? If I can help in any way I am more than
> willing to do so! :-)
>
> Kent Larsson
> Utvecklare
>
> Euroling AB
> Igeldammsgatan 22C
> 112 49 Stockholm
> 08-519 00 522 (direkt)
> 08-519 00 500 (växel)
>
> Euroling SiteSeeker - Sökning och analys för webbplatser och intranät
>
>
>
> On Mon, Aug 30, 2010 at 8:27 AM, Kent Larsson <[hidden email]> wrote:
>> Yes. Unfortunately it doesn't matter if I have it checked or not. If I
>> make sure to delete it manually and make 100% certain that it is gone,
>> the error is still there.
>>
>> Kent Larsson
>> Utvecklare
>>
>> Euroling AB
>> Igeldammsgatan 22C
>> 112 49 Stockholm
>> 08-519 00 522 (direkt)
>> 08-519 00 500 (växel)
>>
>> Euroling SiteSeeker - Sökning och analys för webbplatser och intranät
>>
>>
>>
>> 2010/8/28 Grégory Boissinot <[hidden email]>:
>>> Regarding the log, the execution is correct.
>>> The warning with the message 'Can't create the path' is due the fact
>>> that the directory already exists:
>>> - It has not be deleted the previous run
>>> - The option 'Delete generated output' is unchecked.
>>>
>>> Have you got any comments?
>>>
>>> 2010/8/27 Kent Larsson <[hidden email]>:
>>>> Hi,
>>>>
>>>> Thank you for answering! I'll do my best to describe our experience
>>>> with the problem.
>>>>
>>>> I upgraded to 1.7 today. Unfortunately we still experience the same problem.
>>>>
>>>> We have the dotnet job running on a Windows slave running Windows
>>>> Server 2008, our master is running Ubuntu.
>>>>
>>>> The plugins we use: http://i.imgur.com/m0rFx.png
>>>>
>>>> This is how our job configuration looks: http://i.imgur.com/St2zu.png
>>>>
>>>> And this is the console output for that job: http://i.imgur.com/ZogTg.png
>>>>
>>>> As you can see from the console output (the xUnit output is last) the
>>>> path seems a bit strange.
>>>>
>>>> Best regards,
>>>> Kent Larsson
>>>>
>>>> 2010/8/27 Grégory Boissinot <[hidden email]>:
>>>>> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>>>>>
>>>>> 2010/7/26 Joris Koster <[hidden email]>:
>>>>>> Hi
>>>>>>
>>>>>>
>>>>>>
>>>>>> We’re running Hudson on x64 Win7 machine. We used to login into the
>>>>>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>>>>>> Unfortunately each time when the machine reboots we need to go through that
>>>>>> cycle again, so I opted for installing it as service instead (log in as
>>>>>> admin and start through JNLP à install as service).
>>>>>>
>>>>>>
>>>>>>
>>>>>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>>>>>> version we were running; let’s say some version from May):
>>>>>>
>>>>>>
>>>>>>
>>>>>> Archiving artifacts
>>>>>>
>>>>>> [xUnit] Starting to record.
>>>>>>
>>>>>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>>>>>> due to exception
>>>>>>
>>>>>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>>>>>
>>>>>> at
>>>>>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> at hudson.model.Executor.run(Executor.java:124)
>>>>>>
>>>>>> Caused by: hudson.util.IOException2: remote file operation failed:
>>>>>> c:\hudson\workspace\Windows32Debug at
>>>>>> hudson.remoting.Channel@127d3b74:Oberon
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> Finished: FAILURE
>>>>>>
>>>>>>
>>>>>>
>>>>>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>>>>>> 1.6) and set "Fail the build if test results were not updated this run" =
>>>>>> True:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Archiving artifacts
>>>>>>
>>>>>> [xUnit] Starting to record.
>>>>>>
>>>>>> [xUnit] Can't create the path
>>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>>> already exists.
>>>>>>
>>>>>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>>>>>> failed: c:/hudson/workspace/Windows32Debug at
>>>>>> hudson.remoting.Channel@2110ba:Oberon
>>>>>>
>>>>>> Finished: FAILURE
>>>>>>
>>>>>>
>>>>>>
>>>>>> Next I decided to revert to running from the user account instead of
>>>>>> as-a-service:
>>>>>>
>>>>>> Archiving artifacts
>>>>>>
>>>>>> [xUnit] Starting to record.
>>>>>>
>>>>>> [xUnit] Can't create the path
>>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>>> already exists.
>>>>>>
>>>>>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>>>>>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>>>>>> 'c:\hudson\workspace\Windows32Debug'.
>>>>>>
>>>>>> [xUnit] [INFO] - Converting
>>>>>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>>>>>> .
>>>>>>
>>>>>> [xUnit] [WARNING] - Can't delete the file:
>>>>>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>>>>>
>>>>>> [xUnit] Stopping recording.
>>>>>>
>>>>>> Finished: SUCCESS
>>>>>>
>>>>>>
>>>>>>
>>>>>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>>>>>> result; I’ve tried running the service on the builder account à same result
>>>>>> (as service).
>>>>>>
>>>>>> Next I tried comparing the environment (‘System Information’) between
>>>>>> running as service and as user, and there are a lot of differences… I think
>>>>>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>>>>>> a run-as-service with correct or incorrect, but different results.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fortunately we can just continue on our old scheme (login into the builder
>>>>>> account and start through JNLP manually) since that will just report the
>>>>>> builds succeeded (and failed when actually a unit-test or compile failed).
>>>>>>
>>>>>>
>>>>>>
>>>>>> We would like to run as service however, so maybe I’m missing some settings
>>>>>> to accomplish this, any clues/ideas would be welcome.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>> Joris Koster
>>>>>>
>>>>>> Senior Software Developer
>>>>>>
>>>>>> Paragon Decision Technology
>>>>>>
>>>>>> www.aimms.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>>>>>> privileged. If you are not a named recipient, please notify the sender
>>>>>> immediately and do not disclose the contents to another person, use it for
>>>>>> any purpose or store or copy the information in any medium.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Kent Larsson

Re: hudson as a Win7 service + xUnit/cppUnit

Ops, wrong URL. It's in JIRA anyway.

Kent Larsson

On Mon, Aug 30, 2010 at 10:52 AM, Kent Larsson <[hidden email]> wrote:

> Hi again,
>
> I created a bug report for this issue:
> http://hudson.361315.n4.nabble.com/hudson-as-a-Win7-service-xUnit-cppUnit-td2302125.html#a2302125
>
> Best regards,
> Kent Larsson
>
> On Mon, Aug 30, 2010 at 9:28 AM, Kent Larsson <[hidden email]> wrote:
>> Hi again!
>>
>> I double checked as I can't trust myself! ;-) But it seems I were
>> correct, I now have this configuration http://i.imgur.com/QsrIG.png
>> and this console output http://i.imgur.com/LsIJh.png . Do you have an
>> idea on what it could be? If I can help in any way I am more than
>> willing to do so! :-)
>>
>> Kent Larsson
>> Utvecklare
>>
>> Euroling AB
>> Igeldammsgatan 22C
>> 112 49 Stockholm
>> 08-519 00 522 (direkt)
>> 08-519 00 500 (växel)
>>
>> Euroling SiteSeeker - Sökning och analys för webbplatser och intranät
>>
>>
>>
>> On Mon, Aug 30, 2010 at 8:27 AM, Kent Larsson <[hidden email]> wrote:
>>> Yes. Unfortunately it doesn't matter if I have it checked or not. If I
>>> make sure to delete it manually and make 100% certain that it is gone,
>>> the error is still there.
>>>
>>> Kent Larsson
>>> Utvecklare
>>>
>>> Euroling AB
>>> Igeldammsgatan 22C
>>> 112 49 Stockholm
>>> 08-519 00 522 (direkt)
>>> 08-519 00 500 (växel)
>>>
>>> Euroling SiteSeeker - Sökning och analys för webbplatser och intranät
>>>
>>>
>>>
>>> 2010/8/28 Grégory Boissinot <[hidden email]>:
>>>> Regarding the log, the execution is correct.
>>>> The warning with the message 'Can't create the path' is due the fact
>>>> that the directory already exists:
>>>> - It has not be deleted the previous run
>>>> - The option 'Delete generated output' is unchecked.
>>>>
>>>> Have you got any comments?
>>>>
>>>> 2010/8/27 Kent Larsson <[hidden email]>:
>>>>> Hi,
>>>>>
>>>>> Thank you for answering! I'll do my best to describe our experience
>>>>> with the problem.
>>>>>
>>>>> I upgraded to 1.7 today. Unfortunately we still experience the same problem.
>>>>>
>>>>> We have the dotnet job running on a Windows slave running Windows
>>>>> Server 2008, our master is running Ubuntu.
>>>>>
>>>>> The plugins we use: http://i.imgur.com/m0rFx.png
>>>>>
>>>>> This is how our job configuration looks: http://i.imgur.com/St2zu.png
>>>>>
>>>>> And this is the console output for that job: http://i.imgur.com/ZogTg.png
>>>>>
>>>>> As you can see from the console output (the xUnit output is last) the
>>>>> path seems a bit strange.
>>>>>
>>>>> Best regards,
>>>>> Kent Larsson
>>>>>
>>>>> 2010/8/27 Grégory Boissinot <[hidden email]>:
>>>>>> Could you upgrade the xUnit plugin to xUnit 1.7 and let me know?
>>>>>>
>>>>>> 2010/7/26 Joris Koster <[hidden email]>:
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We’re running Hudson on x64 Win7 machine. We used to login into the
>>>>>>> ‘builder’ account on that machine and start through the JNLP agent (via IE).
>>>>>>> Unfortunately each time when the machine reboots we need to go through that
>>>>>>> cycle again, so I opted for installing it as service instead (log in as
>>>>>>> admin and start through JNLP à install as service).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This however caused the cppunit/xunit plugin to fail (I’m not sure which
>>>>>>> version we were running; let’s say some version from May):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Archiving artifacts
>>>>>>>
>>>>>>> [xUnit] Starting to record.
>>>>>>>
>>>>>>> ERROR: Publisher com.thalesgroup.hudson.plugins.xunit.XUnitPublisher aborted
>>>>>>> due to exception
>>>>>>>
>>>>>>> hudson.util.IOException2: The plugin hasn't been performed correctly.
>>>>>>>
>>>>>>> at
>>>>>>> com.thalesgroup.hudson.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:126)
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> at hudson.model.Executor.run(Executor.java:124)
>>>>>>>
>>>>>>> Caused by: hudson.util.IOException2: remote file operation failed:
>>>>>>> c:\hudson\workspace\Windows32Debug at
>>>>>>> hudson.remoting.Channel@127d3b74:Oberon
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> Finished: FAILURE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I decided to upgrade to the latest version (Hudson 1.367, cppunit 1.7, xUnit
>>>>>>> 1.6) and set "Fail the build if test results were not updated this run" =
>>>>>>> True:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Archiving artifacts
>>>>>>>
>>>>>>> [xUnit] Starting to record.
>>>>>>>
>>>>>>> [xUnit] Can't create the path
>>>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>>>> already exists.
>>>>>>>
>>>>>>> [xUnit] The plugin hasn't been performed correctly: remote file operation
>>>>>>> failed: c:/hudson/workspace/Windows32Debug at
>>>>>>> hudson.remoting.Channel@2110ba:Oberon
>>>>>>>
>>>>>>> Finished: FAILURE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Next I decided to revert to running from the user account instead of
>>>>>>> as-a-service:
>>>>>>>
>>>>>>> Archiving artifacts
>>>>>>>
>>>>>>> [xUnit] Starting to record.
>>>>>>>
>>>>>>> [xUnit] Can't create the path
>>>>>>> /c:/hudson/workspace/Windows32Debug/generatedJUnitFiles. Maybe the directory
>>>>>>> already exists.
>>>>>>>
>>>>>>> [xUnit] [CppUnit-1.x] - Processing 1 files with the pattern
>>>>>>> 'trunk/build/output/win32/debug/unit*.xml' relative to
>>>>>>> 'c:\hudson\workspace\Windows32Debug'.
>>>>>>>
>>>>>>> [xUnit] [INFO] - Converting
>>>>>>> 'c:\hudson\workspace\Windows32Debug\trunk\build\output\win32\debug\unit-test-results.xml'
>>>>>>> .
>>>>>>>
>>>>>>> [xUnit] [WARNING] - Can't delete the file:
>>>>>>> c:\hudson\workspace\Windows32Debug\generatedJUnitFiles\CppUnit\TEST-1187839831.xml
>>>>>>>
>>>>>>> [xUnit] Stopping recording.
>>>>>>>
>>>>>>> Finished: SUCCESS
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’ve tried setting the node root fs to /hudson, instead of c:\hudson à same
>>>>>>> result; I’ve tried running the service on the builder account à same result
>>>>>>> (as service).
>>>>>>>
>>>>>>> Next I tried comparing the environment (‘System Information’) between
>>>>>>> running as service and as user, and there are a lot of differences… I think
>>>>>>> there two issues: a wrong filepath (the slash in front of /c:/Hudson/…), and
>>>>>>> a run-as-service with correct or incorrect, but different results.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fortunately we can just continue on our old scheme (login into the builder
>>>>>>> account and start through JNLP manually) since that will just report the
>>>>>>> builds succeeded (and failed when actually a unit-test or compile failed).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We would like to run as service however, so maybe I’m missing some settings
>>>>>>> to accomplish this, any clues/ideas would be welcome.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Joris Koster
>>>>>>>
>>>>>>> Senior Software Developer
>>>>>>>
>>>>>>> Paragon Decision Technology
>>>>>>>
>>>>>>> www.aimms.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> CONFIDENTIALITY: This e-mail and any attachments are confidential and may be
>>>>>>> privileged. If you are not a named recipient, please notify the sender
>>>>>>> immediately and do not disclose the contents to another person, use it for
>>>>>>> any purpose or store or copy the information in any medium.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]