For Bamboo server, in the xml-data\build-dir\ folder, there are folders with numbers for names that I believe correspond to each local agent (I have 25 agents, and 25 folders in this directory, one for each agent). I want to clear the contents of this entire working directory on a regular basis. If I delete these agent folders, will the bamboo agents simply create new ones here the next time they need to?
I know there's been discussions about how to clean up the working directory on the Atlassian forums, but this is a question more about how bamboo actually works. Do the agents depend on those folders being there, or will an agent create a folder in xml-data\build-dir\ if the previous one has been deleted?
It when you clean ob the directories from the build jobs, bamboo will create new ones when the agent start to build them.
Related
Every time I tried to config a remote interpreter, Pycharm asked me to set a sync folder. In my routine, I usually have the Cannot find declaration to go to error which can not be solved by invalidating caches. So I have to config the interpreter again. And these caused the redundant folders in my remote machine. And another situation is that I want to create other projects with the same interpreter. Where I have to config the folder mapping for each project to make the interpreter valid.
I do not understand this way. In my opinion, the sync folders should correspond to my local project. And the interpreter should be independent of the projects.
Every time I tried to config a remote interpreter, Pycharm asked me to set a sync folder.
To be able to execute a script on the remote machine, it is necessary to make sure it exists on it. This is by design, but if you already have a project folder deployed, you can change the suggested paths to needed ones during the interpreter configuration.
See step 7. https://www.jetbrains.com/help/pycharm/configuring-remote-interpreters-via-ssh.html#ssh
And another situation is that I want to create other projects with the same interpreter. Where I have to config the folder mapping for each project to make the interpreter valid.
Unfortunately, this setup does not work, please vote for
https://youtrack.jetbrains.com/issue/PY-40680/Allow-reusing-a-single-remote-interpreter-in-multiple-project
to increase its priority.
One of my servers is running out of capacity, mostly due to WebLogic's stage folder. I've been looking for information and it seems to be a temporal folder, but unlike older versions, on WL11g this folder is out of the tmp folder. So I'm not sure whether or not I can safely remove it.
Stage directory is where weblogic copies all the applications that it needs to deploy on to the managed servers. Wls does not delete any file from this folder. So in the long run if you have done deployment of many versions of your application then this folder can become rather large.
So yes you can delete the contents of this folder. At the time of restart wls will copy all the necessary files to this folder (this could take some time).
yes, you can delete the stage. All the necessary applications details will be there in this directory, but any how if it is a large environment(many applications are running), just take the back up of the directory or rename it and then you can safely delete the stage.
I have an IIS web application with a structure roughly similar to:
wwww.mysite.com
file1.asp
file2.asp
\DotNet
file3.aspx
file3.aspx
We are setting up TeamCity to do auto deployments. I have an MSBuild build step that deploys to the \DotNet folder (the aspx files), and in a separate build configuration I have another MSBuild build step that deploys to the root (the asp files).
I want to allow MSDeploy to delete unnecessary files, e.g. if I remove file2.asp from VCS, I want it to delete it from the target IIS server.
However, I do NOT want it to wipe the \DotNet subfolder.
Can I get something more granular than the command line switch "SkipExtraFilesOnServer", or is this an all-or-nothing deal?
It turns out that the answer to my question was much simpler than I expected
When deploying to the root folder of an application using the MSDeployPublish target via MSBuild, by default, extra subfolders that happen to be on the filesystem of the target IIS server are deleted.
To avoid this, I simply moved the contents of my DotNet folder to a totally separate location under C:\InetPub, but retained my original virtual folder/application structure under IIS Mgr. Of course!
Now I can publish to either location as much as I please, and one won't try and delete the other because one is no longer a filesystem subfolder of the other.
If anything - this highlights how primitive our earlier folder structure was, and what a doofus I am for not realising.
I'm not exactly sure what you're looking for here. Are you trying to delete all the files from within the dotnet subfolder but keep the folder? Are you trying to have the delete operation never delete anything from the dotnet folder? The msdeploy sync operation is pretty smart. msdeploy will move all of your marked project assets, so assuming you don't delete the files in the dotnet folder, then you should be fine.
If you just want to exempt the dotnet folder from any delete actions, as if it were a not part of your project at all, but its in a subfolder the web server and you want to not touch it, then I would suggest using the skip option in msdeploy with wildcards. I've only used it for files, but it should work for folders too. It goes like so:
-skip:objectName=filePath,absolutePath=app_offline\.*
There's documentation here: http://technet.microsoft.com/en-us/library/dd569089%28WS.10%29.aspx
Search the page for
-skip:skipAction=
You could also add a skip setting with name of the folder you wish to not by synced, like in the following msdeploy call:
msdeploy
-verb:sync
-source:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Source"
-dest:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Dest"
-skip:objectName=dirPath,absolutePath="DotNet"
[I took the example from the answer to this question.]
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
An MSBuild project copies its output to a directory on a server. Each day, only a few files change and most have an older creation date.
I can FTP this to a remote server with MSBuild tasks. But how can I do this FTP and only copy the few files that have changed?
To do this you'll need something that will manage the sync for you - that is that will keep track of what file is where and update accordingly.
We have used FTPSync to do the file sync bit very tidly for a number of sites.
From MSBuild you can call an external program - so putting the two together will probably work providing your are consistently synching from the same location (otherwise its going to be more interesting!)