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

Git clean on Multi Configuration build requires re-clone of slave repo

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • OS X, Windows7, Linux. Jenkins 1.462

      I've just set up a Multi Configuration job: a master with no build responsibilities & 3 slaves (mac, win, linux). I see that the master clones a copy of the source repo into the root of one of the slave's workspace: workspace/projectname/contentsofrepo.

      Then, the slave clones a separate copy of the same repo for its own purposes: workspace/projectname/label/osx/contentsofrepo.

      I prefer to use the "Clean after checkout" option for my git projects, to ensure a clean workspace on a fresh build. However, with this enabled the master's git repo sees the slave's repo (again, located within the master's copy) as a directory not tracked by git and removes it, meaning that when the slave runs, it has to re-clone the entire repo, which takes about a half hour for our project.

      I would expect the master & slave's copies of the repos to not overlap with one another such that they could be cleaned independently of one another.

          [JENKINS-13685] Git clean on Multi Configuration build requires re-clone of slave repo

          A few more details: The master node is on an OS X 10.6 machine, installed jenkins 1.462 via homebrew: https://github.com/mxcl/homebrew/blob/master/Library/Formula/jenkins.rb

          Liam Staskawicz added a comment - A few more details: The master node is on an OS X 10.6 machine, installed jenkins 1.462 via homebrew: https://github.com/mxcl/homebrew/blob/master/Library/Formula/jenkins.rb

          Mark Waite added a comment -

          Confirmed this is still a bug with git-client-plugin 1.6.4 and git-plugin 2.0.4. I suspect the issue lies more with the multi-configuration project placing the label/slave-name in the top level directory, but am not sure another solution is feasible.

          Refer to the attached picture trying to illustrate the problem. One of the slaves is selected to host the "root workspace", and if that slave also is used as part of that multi-configuration job, then there will be a label/slave-name directory within the root workspace on the slave. When the clean is performed in the root workspace, it will remove the label/slave-name directory completely.

          Mark Waite added a comment - Confirmed this is still a bug with git-client-plugin 1.6.4 and git-plugin 2.0.4. I suspect the issue lies more with the multi-configuration project placing the label/slave-name in the top level directory, but am not sure another solution is feasible. Refer to the attached picture trying to illustrate the problem. One of the slaves is selected to host the "root workspace", and if that slave also is used as part of that multi-configuration job, then there will be a label/slave-name directory within the root workspace on the slave. When the clean is performed in the root workspace, it will remove the label/slave-name directory completely.

            Unassigned Unassigned
            liamstask Liam Staskawicz
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: