mdonohue commented on HUDSON-682:
Another interpretation of this would be a nice UI that does the locks-and-latches plus custom workspace setup properly for a group of jobs with a single setting, instead of managing these things on each job, and leaving open the possibility of configuration skew.
Even in the read-only case, a common use-case appears to be sharing the IO cost among jobs by having a common parent do checkout or some other IO intensive task, and then the other jobs can just read that data without having to copy it anywhere, since it lives in a shared workspace.
But this use-case is in contrast to the original description, so I think the workspace-copy idea is in line with what was originally described. We'll have to have new bugs for the other use-cases.
> 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.