Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-7324

Allow modules to be built on separate hudson slaves

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • ivy-plugin
    • None

      Hello.
      We are attempting to use the Ivy plugin to run parallel module builds across multiple slaves. Unfortunately the plugin currently only allows parallel module builds on a single slave (with multiple executors). Our builds require individual slaves to run modules because of external dependencies that are shared between tests and configurable via environment variables - such as an sql database for acceptance tests - so multiple executors does not do the job.

      Thanks.

          [JENKINS-7324] Allow modules to be built on separate hudson slaves

          mishnya added a comment -

          Very waiting for this issue, cause it becomes impossible to built ivy based project that consists of modules that must be build on different envieronments.

          mishnya added a comment - Very waiting for this issue, cause it becomes impossible to built ivy based project that consists of modules that must be build on different envieronments.

          I would definitely like to have this feature myself, but at present I really don't see when I will have time to tackle it. It isn't an easy change to make as the plugin is currently coded with the assumption that the whole workspace has been checked out once and will remain where it was checked out. The workspace-choosing logic is only in the parent build, so a new slave is only ever selected when a new parent build gets triggered. The module builds have no workspace selection logic at all, they just delegate to the parent.

          Allowing modules to run on different slaves would mean that any time a module build started on a different slave the workspace would need to be replicated somehow to the new machine (or re-checked out from the identical revision).

          Anyway, I'm all for this change, but I'm not going to have time to do it myself. If anyone wants to attempt it themselves, a patch would be most welcome. Alternatively, you can fork the git repo at https://github.com/hudson/ivy-plugin, have a play with the code and submit a pull request when you have something working.

          Timothy Bingaman added a comment - I would definitely like to have this feature myself, but at present I really don't see when I will have time to tackle it. It isn't an easy change to make as the plugin is currently coded with the assumption that the whole workspace has been checked out once and will remain where it was checked out. The workspace-choosing logic is only in the parent build, so a new slave is only ever selected when a new parent build gets triggered. The module builds have no workspace selection logic at all, they just delegate to the parent. Allowing modules to run on different slaves would mean that any time a module build started on a different slave the workspace would need to be replicated somehow to the new machine (or re-checked out from the identical revision). Anyway, I'm all for this change, but I'm not going to have time to do it myself. If anyone wants to attempt it themselves, a patch would be most welcome. Alternatively, you can fork the git repo at https://github.com/hudson/ivy-plugin , have a play with the code and submit a pull request when you have something working.

          andrew beck added a comment -

          I was wondering if the original submitter found a workaround for possibly paralleling the module builds across multiple slaves. The worksplace issue could be overcome by creating networked symbolic links to a common location where all slaves could share the same workspace.

          andrew beck added a comment - I was wondering if the original submitter found a workaround for possibly paralleling the module builds across multiple slaves. The worksplace issue could be overcome by creating networked symbolic links to a common location where all slaves could share the same workspace.

            tbingaman Timothy Bingaman
            amleszk amleszk
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: