In my TFS 2010 build definition, if I have the setting CLEAN WORKSPACE = ALL, the directory (c:\builds\Binaries) on the TFS agent machine is deleted. While the build itself succeeds, its output fails to drop to the specified drop location. (The error: "TF270003: Failed to copy. Ensure the source directory c:\builds\Binaries exists and that you have the appropriate permissions.")
If (after first recreating the c:\builds\Binaries directory) I set CLEAN WORKSPACE = NONE, the build still runs successfully, without getting the drop error. However, there is still no build output, even though the setting DropBuild = True.
Why would the CLEAN WORKSPACE setting delete a directory without recreating it? Is there another setting used to recreate this directory on the build agent? Is there a downside to using CLEAN WORKSPACE = NONE? And when I use CLEAN WORKSPACE = NONE, and have a successful build, any ideas why the build is not being dropped to the output location, even though DropBuild = True? (Note that the build log does successfully drop to this location.)
Nothing is ever placed in c:\builds\Binaries during a successful build, even though I've opened up full permissions for everybody on that directory of the build agent server.
Any ideas would be appreciated.
I experience similar issue when "Project to Build" path under "Process" is different from "Source Control Folder" of "Workspace" section.
The problem going away as soon as I changed the path to make sure they are match.
I had the same issue today. I changed DefaultTemplate workflow and it is working now. What I did:
I removed all occurrences of BinariesDirectory parameter from DefaultTemplate.
Update MatchPattern parameter for FindMatchingFiles activity
Update BinariesRoot parameter for GetImpactedTests activity
Related
I'm running an inherited project and it seems to sometimes work, but for what seems like 99% of the time, I get the Failed to copy full contents from... error which I have found to be attributable to folder permissions.
I've used chmod recursively to set the parent folder and its children to 777, but when I run mvn clean install -DskipTests, it removes the target folder and replaces it with a new target folder with apparently read-only access.
Is there a way to make it so it just knows to create the child folder with read-write access when creating it? I feel as though I'm missing something here.
Edit: I should also point out that sometimes (only SOMEtimes), the mvn operation succeeds when I delete the target folder. Any idea how this works only sometimes?
In TFS the Build number format usually looks something like this:
$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
However, I only want to retain 1 build and I would like it to build to the same folder each time. So I tried changing it to this:
$(BuildDefinitionName)
But the problem is that this only works one time, then gives an error that the build number already exists after that. I would like to build to the same folder so that I can write a script to zip the latest build, move it to another place, and then unzip it and it would just be much easier if I didn't have to deal with writing code to figure out what the most recent folder name is.
Is there a way to accomplish building to a folder name that doesn't change?
This is by designed, every completed build should has a unique build number/name. Otherwise you will get the error above.
$(Rev:.r)
Use $(Rev:.rr) to ensure that every completed build has a unique
name. When a build is completed, if nothing else in the build number
has changed, the Rev integer value is incremented by one.
As a workaround: For vNext build, you could use a copy Files task to copy the build output to the same folder during the build pipeline. To make sure you will always only get the latest build, you could add a powershell script before the copy task to clean/delete files in that special target folder.
For XAML build you need to customize the build template and add the default CopyDirectory activity in build template to copy the build result to the specified drop location. The detailed steps please refer to this blog. Also add a pre-build script to do the clean operation.
When I create a new project in XCode 6.0.1, I got this error message: The file "exclude" doesn't exist
It seems to only impact the versioning of the files i.e. the generated stub files are not committed into github after the project is created.
What can cause this problem?
For me the issue was caused because I had previously created a project with the same name, and Xcode still had record of that.
To clear it out,
go to Window -> Organizer in the menu bar
Remove all of the repositories highlighted in red
To add your repository (if it's not being tracked for some reason),
Click the + (still in Window -> Organizer from the steps above)
Enter the path of your file
Make sure to change to Git from Subversion (if Xcode has Subversion set as default - it did for me.
I usually get this error if I initialize an Xcode project with a git repository, delete it and try to recreate it with the same name (casing doens't appear to make it sufficiently 'different'). Turns out, "Well I'll just start over" can leave some issues as well.
Hope this helps.
I had this issue as well, and I tracked it down to the .git-template folder included with Thoughtbot's dotfiles. Basically, Xcode expects its template folder to have info/exclude, and Thoughtbot's dotfiles don't. Creating that directory and file fixed the problem, as so (in the Terminal):
cd ~/.git_template
mkdir info
cd info
touch exclude
If you're getting this issue without Thoughtbot's dotfiles, you could probably look at ~/.gitconfig and use whatever templatedir is getting set as instead of ~/.git_template in the first command.
I have checked the option in TeamCity which says "Clean all files in the checkout directory before the build". But it doesnt seem to delete the folder on the server before it builds and deploys the code. There are always stray files which are no longer needed. Is there any better process / Can we achieve by adding extra command line parameters to Build Step to achieve this?
Thanks.
Try setting specific folder as the Build Checkout Directory (instead of using default one). You can set this in your VCS Settings page.
You would also need to select the option the to clean directories before checkout for every run. Otherwise you wil still be left with the issue of stray files
Is it possible to make TeamCity only clean up certain files upon fetching files from my git repo? I modify one file as a build step, and thus always need a clean version of that file. However, it's really unnecessary to fetch the whole repo everytime because usually only a few files are modified (thus, I'd rather not use the 'Clean all files before build' command).
Thanks!
To clarify, lets say I have the following structure:
- index.html
- js/script.js
- js/plugins.js
I only want to always (regardless if any change has happened) to checkout index.html. The files in the js folder I only want to replace whenever any updates on them have happened.
If you are using TeamCity 6.5 or above you can use the Build Files Cleaner (Swabra) Build Feature. Once you have added it your build steps and run clean build it will clean any new unversioned files generated during the build either before the new build starts or at the end of the current build.
I personally prefer to run it before the new build starts as it allows you to look at any of the output when trying to work out why something went wrong.
Basically it makes sure that there is nothing in the build agents work folder that was not pulled from the repository before each build.