abayer commented on HUDSON-682:
@akostadinov - The biggest difference is that it'll be formalized - there won't be a need to do the zipping/archiving/downloading/extracting manually, and there'll be an automatically defined relationship between the parent build and the child build. Also, we'll be able to have the child build inherit the parent build's SCM changelog. You're right in that this won't do much for lowering IO/disk space usage, but it will answer most of the use cases mentioned in earlier comments here, so that's what I'm going after.
> Share workspace between jobs
> Key: HUDSON-682
> URL: http://issues.hudson-ci.org/browse/HUDSON-682 > Project: Hudson
> Issue Type: Improvement
> Components: other
> Affects Versions: current
> Environment: Platform: All, OS: All
> Reporter: mmatula
> Assignee: abayer
> Priority: Critical
> Seems that the usual way how jobs work on hudson is that there is one job for
> building a project and then if I want to have a subsequent job to run all unit
> tests, that job needs to download artifacts produced by that build job from
> Hudson. As a consequence, people usually add separate targets to their build
> scripts for running unit tests from hudson which download the build artifacts
> from the network.
> I think it would be nice if things could work the way how users would do it when
> running tests locally - i.e. use usual targets for building and then simply run
> a target for unit tests in the same workspace. This could be achieved by
> providing the subsequent jobs an exact snapshot of the workspace at the time
> when the parent job finished running.