Search code examples
jenkinstfsjenkins-pipelinejenkins-plugins

How to prevent Jenkins to get the entire TFS workspace?

I am trying to build a single project in what is essentially a monorepo.

Using the TFS plugin in Jenkins I set the Project path to the specific project I want to build, and set the local workfolder in advanced settings accordingly. This way I could get all the project dependencies from the monorepo that I need to build this one project using a script inside the Jenkinsfile. At least that is what I thought.

As soon as I mapped the Jenkins workspace to the repository root, Jenkins seems to get the entire repository on build, which eventually fails with an out of memory exception, completely ignoring what I set in "Project path".

But even if it wouldn't fail, it's not really a realistic idea to have a complete copy of the entire repo for every project we want to build.

How can this be solved? Stop using the TFS plugin and do all TFS operations in the Jenkinsfile maybe?

Solution

  • Assume you have $/Repo/project and $/Repo/dependency . You just need to pull both of those into Jenkins for a single build. Naturally you tried $/Repo root, but this gave you a bunch of other projects along with.

    Completely ignoring what I set in "Project path". You may use multiple project path.

    The TFS pluging for Jenkins currently does not support checking out the sources from multiple locations.

    As a solution, just as Ian W pointed out you have ability to cloak folders in your $\Repo that you are not interested in. Checkins to cloaked folders will not trigger a build. Unfortunately according to your comment that may be a lot of folders.

    Another solution to this is to create several Jobs, some that just download your dependency and another to make the build.

    For example, create three jobs in Jenkins, each "downstream" of the other:

    Try to build uses $/Repo/project (as workspace\TheProgram), and $/Repo/dependency (as workspace\Framework).

    • Framework-Get: normal source code triggering on TFS' Project Path of $/Repo/project. No build step.
    • TheProgram-Get: normal source code triggering on TFS' Product Path of $/Repo/dependency. No build step.
    • TheProgram-Build: No source code control. But the build steps xcopy's the source from the above two steps. Then, you can run a normal build step.

    TheProgram-Build's first build step is a windows batch command:

     REM ==================================== REM First Get the
Framework folder: rmdir /s/q Framework mkdir Framework xcopy /y /q /e
..\..\Framework-Get\Workspace\Framework Framework

REM ==================================== REM Then Get the TheProgram
Folder: rmdir /s/q TheProgram  mkdir TheProgram  xcopy /y /q /e
..\..\TheProgram-Get\Workspace\TheProgram TheProgram

    The second build step was a simple call to build use msbuild or whatever you like here.

    You could also combine job1 and job3 together to simplify your workflow, which actually only need two jobs.