Is there a way in teamcity to restore a deleted build configuration. I found Restore just deleted project which is about restoring a deleted project but can't find any information about restoring a deleted build configuration. I am using Teamcity 8.0.6
TeamCity 9, locate your data directory and you'll find a trash folder, like so:
D:\TeamCity\Data\config\_trash
Take a copy of the whole thing to some other folder, just in case.
Move the effected project folders from config\_trash to config\projects.
Remove the suffixed .projectNN from each project folder.
You may see critical errors in the main web portal while this is happening.
Restart TeamCity just for good measure.
The previous versions of build configuration setting are stored in /config/projects/buildTypes folder in different *.xml.N files. To restore setting replace *.xml file with *.xml.N file.
Also since TeamCity 9 it is possible to store all project setting in VCS.
Another option, available since 9.0 is to place project settings in version control (Git, Mercurial, or Subversion and Perforce since 9.1), and then restore removed files using VCS commands.
Related
We have used the following TFS Deployment strategy used for Websites -:
1) Windows Machine File Copy
Source : Folder of TFS
Target : Application Server
Now, in a folder placed inside this website, files are first deleted and then added/ re-created.
But after deploying through TFS, files are made Read-Only. So files can't be deleted and error is thrown on the website.
How to handle this case in TFS deployment
I'm assuming your build a server workspace or you are directly pulling files from TFVC into a server workspace (see local vs. server workspaces). In a server workspace files that are not check-out are read in the workspace to prevent you from making changes locally without first telling TFS you are going to changes them (check-out). Since your build will usually not perform any source control operations in your workspace some or or all files remain read-only when you copy them or publish them as artifacts.
If you copy items from TFS to another location these read-only flags are also copied. However this is easily fixed by using attrib -r to clear the read-only flag either before publishing the artifacts from your build or before (or after) copying the files over to the target machine. See the attrib documentation for more options like recursion.
When you set a folder path as the Physical Path for a website in IIS 6.0, you will see that the folder are made to Read-only automatically.
You could remove the Read only setting for this folder in the folder property. If you want to remove the read only setting for your folder. In the Windows Machine File Copy step, you need to provide an account which is the administrator of the target machine.
Problem has been resolved by adding one attribute of Windows robocopy command.
/A-:R : Removes the Read only attributes from copied files.
"/A" : attribute
"-" : remove
"R" : Read only property
I have a brand new Visual Studio 2015 project stored in a TFS Git repo. I've configured a build using the standard Default Git build template. The new project builds locally just fine, but fails during the TFS Build with the following error:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.
When TFS first creates your Git repository, it includes a default .gitIgnore file which "hides" certain files from your your (Pending) Changes window. One of the wildcard based exclusions in the default .gitIgnore file specifically excludes any files from being checked in under any folder that includes "build/" which includes this specific file. For now, I've commented out that exclusion in the file, and now it shows up in my (pending) Changes window.
My team created a project. This project has already existed on each PC of each member. Now, I have just added this project to SVN using AnkhSVN. So I want to know how to each memeber of my team can use this project without check out or download this project because it has already existed. I want to using any SVN client to refer to it or something like that. Any idea for me ?
Short answer: they have to use SVN checkout into empty folders, sorry.
Ask your team members to:
create new folder named "fromsvn",
make an SVN checkout of project into that folder,
copy with replace existing project into "fromsvn" folder,
commit changes if there are any.
Long answer:
During checkout SVN creates folder named ".svn" in each folder. This ".svn" folder contains the so-called "base" versions of your files. Each "base" version is a copy of the original file which is inside SVN.
When you make "clean" checkout (i.e. you download project from server into empty folder using SVN client), SVN creates both "base" versions of files (and puts them into .svn folder) and "working copy" - the ones you actually will modify and then commit. Thus, if you checkout 10Mbytes project, SVN will create 20Mbytes of files, half of which will be stored in ".svn" folder, but it will download only 10Mbytes from server.
Other members already have their projects, but they do not have ".svn" folders. It means, that SVN client still have to download those folders from SVN server repository, and it will still cost those 10Mbytes.
We have a TFS build definition set up where we pass the following extra MSBuild arguments in:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\server\build";AutoParameterizationWebConfigConnectionStrings=false
This has been detailed elsewhere as a way to have the published files copied to a specific location instead of generating a deploy package.
This unfortunately does not work on our build server, however if I run the exact same msbuild command line as called by TFS on my dev machine then it works perfectly and copies the output files to the location.
I have checked the log file and there is no errors, it just seems to completely skip the publish/deploy step.
Done building target "_BuiltWebOutputGroupOutput" in project "xyz.csproj".
Target "PrepareForRun" in file "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets" from project "C:\Builds\2\xyz\xyz build\Sources\xyz.Web\xyz.Web.csproj" (target "CoreBuild" depends on it):
whereas on my local machine, after _BuiltWebOutputGroupOutput target is run the package target runs and deploys the files correctly.
I have tried using different paths and even setting the properties in the project file but it seems to make no difference. My local solution and project files are the same as in the repository that the TFS build is using. Is there something config related on our build server or with the build agent that would cause the packaging target not to run?
I was having a similar problem today and found a fix so it maybe worth a look for you. Here
I am trying to upload a solution with multiple projects but only the first project gets uploaded. When I try to load any of the others I get error "Project cannot be added to Subversion because it is out of working copy"
The folder structure on the drive is:
c:\myprojects\thisproject\project1
c:\myprojects\thisproject\project2
c:\myprojects\thisproject\project3
How do I remove a solution from the SVN library via VisualSVN? I don't see a remove solution, just add a solution.
I don't believe it's possible to remove a solution from SVN via VisualSvn. The options are either delete or export and only delete can be done, but that also removes the file from the solution and in most cases from the harddrive. VisualSvn offers minimal SVN features: update, commit, delete and branch commands.
I recommend if you are having problems with svn that you used Export from TortoiseSVN. Export removes all the .SVN folders from your solution and copies them to a new location.
If project1 is the root of your subversion repository, project2 or project3 will not add to your subversion repository.