Cause I have a machine that's used for build purpose, and a machine that's used for regression/unittest.
So the output files that trace the code coverage, are actually produced on machine that run the regression/unittest, but these coverage files (.gcda files) and must be joined with the repository (specificly the .o and .gcno) that was used to create the exe, and that repository resides in the build machine... I could build and run the regression/unit tests on the same machine, but we have a dedicated machine used for build, and other machines used for testing. On Thursday, August 29, 2013 10:23:50 PM UTC+3, JonathanRRogers wrote: > > On Wednesday, August 28, 2013 5:10:38 PM UTC-4, Avihay Eyal wrote: >> >> Hi, I have a job that builds a debug version, and a job that runs >> regression tests and publish code coverage. The code coverage (gcovr) needs >> *access to the code base* itself, >> which is close to *3 GB.* I've tried *archiving* the workspace in the >> build job, and using that archive in the regression job, but the archiving >> *takes forever*... >> >> So I want to use *rsync* from the build machine to the regression >> machine, is that the *best practice for the situation I described? *To >> me it seems that the drawback is that I'm using the actual >> machine names, when doing the rsync, therefor eliminating the abstraction >> of jobs and nodes... >> > > So you need a job to have access to the output of a previous job? Why not > just have the gcovr job run on the same machine with the same workspace? > -- 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/groups/opt_out.
