Our Jenkins server is running out of disk space on the primary partition because the default workspace folder in /var/lib/jenkins/workspace is growing too large. I need to move the workspace to a different mounted drive with more storage. Is it better to change the workspace root at the global system level, or should I use the 'Use custom workspace' option within individual project configurations? Also, will changing this path affect my current build scripts that rely on relative file paths?
3 answers
To change the workspace globally, go to 'Manage Jenkins' > 'System' and look for the 'Workspace Root Directory' field. You can define a new path using variables like ${ITEM_ROOTDIR}/workspace. However, if you only need to change it for one specific heavy job, open the job configuration, go to the 'General' section, click 'Advanced', and check the box for 'Use custom workspace'. Here you can provide a direct path to your secondary drive. Just ensure the Jenkins user has full 'read/write/execute' permissions on the new directory at the OS level, otherwise, your builds will fail immediately with an access denied error during the 'Checkout' phase.
If I change the workspace location for an existing job that uses a pipeline script, does Jenkins automatically move the old files to the new location, or do I need to manually trigger a fresh 'Git Clone' to populate the new directory?
Moving the workspace is a great way to solve disk issues. I highly recommend using a symbolic link from the old workspace folder to the new drive to avoid breaking any hardcoded paths in older scripts.
I agree with Deborah. Using a symlink is a very "clean" way to handle the migration on Linux servers. It allows the OS to redirect the traffic to the larger drive without requiring any changes inside the Jenkins UI or individual job XML configurations.
Steven, Jenkins will not move your old files for you. When you change the path and trigger a new build, Jenkins treats it as a brand-new environment. It will perform a fresh checkout of your source code into that new folder. This is actually a good opportunity to clean up old build artifacts, but keep in mind that your first build in the new location might take longer than usual because it has to download all dependencies and clone the entire repository from scratch again.