I have Jenkins pipeline projects, and everything works fine as long as I run the project at least once per month. If I wait more than a month Jenkins will delete the workspace for that pipeline project, causing the project to do a brand new git checkout and compile. This results in a super slow build, since all of the intermediate object files/etc are regenerated from scratch.
I cannot find what setting in Jenkins is causing it to clean up these older workspaces. If I modify the pipeline to check out to a custom directory instead of the workspace directory then it works fine, so it doesn't appear to be the git plugin itself, or anything like that.
'Discard old builds' is disabled in the General settings for these projects.
Can someone point me to the setting that is causing 'older' workspaces to get cleaned up for some reason?
Related
So I'm running into a specific issue, I have a Jenkins Declarative Pipeline (from an SVN hosted Jenkinsfile) that is configured to not run concurrent builds and abort previous builds when a new build is triggered.
This works perfectly fine, however the problem I am running into is that Jenkins will re-checkout the whole repository to an #2 suffixed workspace directory for the subsequent build (this ONLY happens when a build is automatically aborted after a new one is triggered, if the first build ends successfully, it re-uses the same directory).
I've seen a ton of threads stating that this is by design, but from what I can see that's only when concurrent builds are enabled, but since it's not I'm confused as to what could cause Jenkins to not re-use the same workspace directory?
If the "why" I require this is necessary, I have a few large repositories (for Unreal Engine games specifically), that I need to build and as an optimization measure for the time in compiling, cooking and uploading the game, it makes perfect sense to cancel old builds but instead Jenkins decides to clean checkout 10+GB of game code and assets (20+ in the case of some other games) in another folder becuase it can't reuse a folder that's not having a job/build executed in it already 😅.
Happy to accept all possible solutions/suggestions as I'm getting a lil' tired of pulling my hair out.
I was facing the same issue with my pipeline. I tried deleting the aborted builds and restarted jenkins. I also deleted the #2 directories in my workspace and only kept the main directory out there. Post this,I didn't face the same issue. This could happen because of the jenkins cache. Make sure that your workspace is correctly reflecting the directory name mentioned in your jenkins file.
I have a working Jenkins TFS setup, but can't figure out how to stop the Jenkins TFS plugin from deleting the whole workspace and downloading it again each time.
I just want it to do the equivalent of "Get Latest" and not delete any files that are up to date.
Here is the message I'm getting in the console when this happens:
Deleting workspace as the configuration has changed since a build was performed on this computer.
I can't figure out what is causing this or how to disable this behavior.
This doesn't always happen when I build the project, so something is causing this to happen.
It can happen even if I don't change any configuration stuff in Jenkins.
Option to "Delete workspace before build starts" option is off.
I have found the message in the Java source for the TFS plugin here, but
don't understand what is causing it: Java TFS Plugin in GitHub
Environment:
Jenkins v2.60.3
TFS plugin 5.121.0
Windows 10 64-bit
Java 1.8
Console log when this happens:
Building on master in workspace D:\Jenkins\workspace\XXX
Deleting workspace as the configuration has changed since a build was performed on this computer.
Downloading list of workspaces from https://tfs.company.com/tfs/Projects...
Deleting workspaces named 'MASTER-XXX' from computer 'ALAN-XXX'...
Deleted 1 workspace(s) named 'MASTER-XXX'.
Querying for remote changeset at '$/XXX' as of 'D2017-08-29T09:46:26Z'...****
In your Jenkins Project configure Page ,there is an option for deleting workspace before build starts in Build Environment section. Double check if you are checking this option or not.
The plugin checks the latest build configuration and compare it with the current job. If there is any difference/change exist, you will see that message. The configuration it checks is the settings in "Source Code Management". Since you mentioned that it also occurs when you didn't do any change, I suspect that it may caused by some variables you used in "Workspace name" changed. You can also check and compare the "build.xml" for the two builds in Jenkins Jobs folder to see what change cause the issue you meet.
JENKINS
I am noticing that the every time I run one of my jobs in Jenkins, there are two files created in the /workspace/build/distributions dir. The two files have the extensions of .tar and .tgz. Every time, I run the job, another set of these files are created. So, if I run the job 3 times, there will be 6 files all together. I have noticed that during the dependency check phase, these artifacts slow things down. Therefore, I wanted to remove them automatically before each time this job runs. I have attempted the configs in the image below. In addition, I have tried the workspace cleanup plugin and that completely deleted the workspace. That is definitely not what I wanted.
Therefore, what would be the best way to go about this.
What scm plugin are you using? Some of the scm plugins allow you to clean the workspace before an update (e.g. SVN's "Emulate clean checkout" and Git's "Clean before checkout" options).
If you're not using a scm plugin, can you remove the files in a batch/shell script during the first build step?
Or perhaps you can go about it from the reverse direction. Can you get rid of the files as the last build step of the job? That way, they are gone when the next build comes along.
We are using TFS2010 for source control and TeamCity 8.x for CI. In our project we have Main branch for releases and bug-fixes and Dev for most of the development. Build steps for both branches are identical. and we have a few build configurations to go through:
I can't seem to make TeamCity to do checkout on a single branch and run build only on the branch that was checked-in to.
First attempt: I've added a VCS Root to point to $/Root that contains both Main and Dev branches and created checkout rules:
First checkin to Main works fine. Checkin to Dev after fails like this:
where DoNotExportAttribute is the file that was modified in the Dev branch. Even if I have
checkbox against "Clean all files in the checkout directory before the build".
My second attempt was to add both of the branches as VCS roots:
But this caused checkout of both branches into the same directory and whatever was checkout first was overwritten by second branch.
Is there a remedy for our case without creating separate configurations for every branch? (we started from config-per-branch, but that proven to be maintenance heavy for the number of steps we do in build)
If I understand correctly, you're trying to use a single TeamCity project for both your main and your branch builds. I would not recommend doing that. By re-using the same project for both your main and your branch builds, you will be sharing version numbers between two different beasts. Version 1.1.4 of the build might be a main build while version 1.1.5 might be a branch build.
By looking at the artifacts created by the build, it will also be difficult to identify which source code was the one selected and included into that artifact. Is the executable a main or a branch executable?
The way we solved the main vs branch problem was by creating a "template" project which contains all our build configurations (each one set up as a Build Configuration Template so they can all be changed in a single location) for building our software. Both the main line and the branch projects are created by copying this "template" project and setting the VCS root to the appropriate directory location.
We run five build agents and each build takes a fair amount of time. Having individual projects for each branch allows us to run builds in parallel if the main and any of the branches happen to have been modified at the same time whereas with one single project, the builds would be done serially.
Hope this helps.
I'm already finishing my project build automation :) with Hudson and Nant.
My project structure is something like
$/Project
build.scripts
script1.build
script2.build
build.properties.xml
Code
Project1
Project2
So Hudson downloads from the root $/Project to the workspace folder.
And everything is ok since the build.scripts are in the workspace, I run them very easily, however what is bugging me is the fact that since the build scripts are inside the workspace, then I can't program Hudson to run automatically either based on time or changes because it will always detect changes to the files (note build.properties.xml which I check out and check in at build time to store some stats).
Where do you recommend these files to go in and still get the advantage of having them source-controlled?
What I ended up doing is to NOT check-in changes to those files. I changed my CI workflow to create another file (local to the workspace only) where the changes are written to.
This way, I still get the last build info written somewhere to pick it up, and avoid the issue of Jenkins detecting the change.
PS: I changed from Hudson to Jenkins since I saw that most plugins ran away from the former. The transition was too smooth to be true.