rsync instead of archiving?

[Avihay Eyal]

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...

[JonathanRRogers]

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?

[Avihay Eyal]

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.

[Daniel Beck]

You could trigger the test/coverage build using Parameterized Trigger plugin, specifying the node name and workspace path the compilation ran on (i.e. the rsync source host and folder) as parameters.

If you're using host names for node names, you're done, otherwise, you need to do a little mapping in your script (or otherwise specify the host name as parameter).

Another option might be to try creating an archive (tar, zip, ...) from the sources before archiving, or using the commercial Cloudbees Fast Archiving plugin.

> --
> 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-use...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Rogers]

Avihay Eyal wrote:
> 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.

If you have the unfortunate situation that you must copy such a large
amount of data from one machine to another, rsync is certainly a good
option. It sounds like you have fairly statically defined roles for
machines, so I don't see the problem with using their host names.

>
> 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 a topic in the

> Google Groups "Jenkins Users" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/D_UDw_7LFIk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> jenkinsci-use...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Jonathan Rogers