abayer commented on HUDSON-682:
Yeah, the problem with actually sharing a workspace is doing so across slaves - unless you set up a network share available to all slaves and put the workspace there (which, actually, is how we do things in my setup, though we're not using one workspace in multiple jobs), I just don't see an elegant way to let both upstream and downstream jobs write to the same workspace. Most of the use cases I'm seeing mentioned here are linear - A runs, then B runs in the same workspace as A so it can reuse the results of A's build, etc. It doesn't handle the circular use case, but, frankly, that's a bit of a crazy use case. For that fairly rare and fairly strange use case, I think the right approach would be to lock both jobs to the same slave and then use a custom workspace - sure, that creates some limitations, but I think they're reasonable.
I've still got some design kinks to work out - what to do if B tries to run but there's no workspace of A available and what to do if B tries to run while A is already running most notably. I'm wondering whether it might make sense to have a publisher that will keep an archive of the most recent completed build's workspace of A, and then B pulls down that archived workspace. We wouldn't have to worry about concurrency collisions with that approach.
> 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.