[JIRA] Commented: (HUDSON-682) Share workspace between jobs

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[JIRA] Commented: (HUDSON-682) Share workspace between jobs

Hudson issues mailing list

    [ http://issues.hudson-ci.org/browse/HUDSON-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136308#action_136308 ]

abayer commented on HUDSON-682:

@akostadinov: I'm leaning towards the archiving approach because it better fits the SCM model - you're getting the controlled workspace of the previous build of job A as the workspace for a build of job B. I want to make sure this plugin can handle these use cases cleanly:

- Job B uses Job A's workspace, but both Job A and Job B have concurrent builds enabled.
- Jobs B, C, and D use Job A's workspace, and all need to get identical copies of Job A's workspace.
- Job B uses Job A's workspace, but Job B doesn't automatically run right after Job A finishes - it runs at a later point in time, when kicked off manually, and by that time, Job A's workspace has been cleaned out, or the slave Job A ran on is no longer available, etc.

Archiving Job A's workspace works in all of those use cases, and keeps the overall picture smoother. There'll be a publisher extension to turn on in Job A to archive the workspace, and an SCM extension to use in Job B, which will let you choose a parent project to use as the SCM source from a list of jobs with the publisher enabled. The SCM extension will handle polling by checking to see if there's a new archive of the parent project workspace (and that the parent project isn't in the process of writing that archive, so we don't get a partial archive), and it'll handle checkout by pulling down the archive and expanding it. I'm not yet sure exactly how the inherited changelogs will work, since this plugin won't know or care what the parent project's SCM is and the changelog is determined by the SCM, but I'll figure that out. =)

This doesn't solve every case, this isn't a perfect solution, but I think it fits the most common use case requested - run a build, and then kick off build(s) of 1..n additional projects to run tests against the results of the first build. So I'm gonna implement it - and me implementing it doesn't mean someone else can't write a plugin to fit another use case. =)  

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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]