I use Capifony to deploy my Symfony2 project to the production server. As a result of the deploy:setup task, folder called /shared/logs were created. However the symfony2 actually refers to /shared/app/logs to store the log files while the shared/logs remains empty.
Anyone know what's happening?
The shared/logs folder is no more created since capifony version 2.1.7.
I've just checked the latest capistrano deploy recipe in trunk and it seems like this's a default behaviour of Capistrano instead of Capifony. It create folders using only the last part of the path of the shared_children array instead of including the full path. Later on in the task deploy:shared_children of Capfifony it create the sub folders with full path.
Related
Hi I am using Octopus Deploy Package Application step to package up my website
I specified the Source Path, Output path etc just fine.
If I do not specify the Include files it brings back everything in the folder structure as the package. But I only want to Package certain things like the CSS, views, dll's etc
If i Specify an include form a sub folderlike /bin/.dll it does not bring the files through, even though this is the exact example they give on the more info icon. but if i specify something in the root like .png which is not in a subfolder it works fine.
Anyone faced this issue. Please see image below to see the step setup
Use the path below, you'll get all dlls in bin folders:
**/bin/*.dll
I understand that Capistrano (v2.15.5) deploys to a different directory and symlinks them in deploy:create_symlink however we have a proprietary module on our web server that breaks on every deploy as its licensed to a specific directory. I understand the advantages of the symlink and being able to rollback etc. but we need to deploy to the same directory. I can't find any documentation which supports this, is it possible without editing the source?
Provided I understood you correctly, this should help:
set :deploy_to, "<proprietary path>"
This will put the releases dir and the current symlink into <proprietary path>.
For more control over all relevant directories, have a look at deploy.rb from the 2.x branch here:
https://github.com/capistrano/capistrano/blob/legacy-v2/lib/capistrano/recipes/deploy.rb
In particular lines 50-66. You can overwrite all the _cset statements with set just like in the example above.
Is there a way to create a "build" but not actually compile the output of the site? Bascially I want to push the files live from the source control in TFS to the final IIS folder destination.
I have used CopyDirectory on my other project builds, but that requires a BuildDetail.DropLocation (compiled Build). Maybe there is another option for the CopyDirectory Source I could use that wouldn't require a build DropLocation.
To simplify, I want to copy files directly from a tfs Source control to a folder, using a Build Template, but that won't compile the files. Is that possible?
While the default .xaml build workflow for Team Foundation Build is indeed a compilation build it does not have to be. I usually recommend teams to at least have one compile and one deploy .xaml workflow.
1) The CompileMyStuff.xaml (DefaultBuildTemplate.xaml) should take my stuff from source control and do whatever is needed to create a Build Drop folder with my output. I may or may not need to actually compile before creating the drop, and it looks like you just want to copy to the drop location.
2) The DeployMyStuff.xaml should take a build number and deploy my code to an environment of my choice.
It looks like you want to skip the "Drop" and go state to deploy and while I would never recommend this you do have a "BuildDetail.BuildLocation" for teh local workspace where the build server has done a get of your code. You can just "CopyDirectory" from there to your server/host for the website.
If you are having a little trouble you could use the Community Build Extensions and fire up PowerShell to do your copy/deploy.
I figured out a solution to this problem. I created a new .xaml file and then the only item that I put in the sequence was "DownLoadFiles". Then I filled out the properties of the task and ran a "build" and it worked.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
I'm trying to use Doctrine with Zend, I have copied the doctrine.php and doctrine file in the script folder in the Source Files folder.
However when I type in command prompt following command: "php doctrine.php" by entering in the scripts folder, Nothing happens, there is no error printed, the cursor just goes to next line. Can someone please tell me how can I use doctrine.php.
When using Guilherme's integration suite, you need to do a couple of things.
Download / clone the Doctrine Common, DBAL and ORM libraries and make sure they're available in your include path. For this, I usually just copy the lib/Doctrine code from each into my project's library folder. If using git, you can add them as subtree splits but that's a topic for another time ;-)
You also need the Symfony Console and Yaml namespaces. Again, it's easiest to place them in your project's library folder under library/Symfony/Component/Console and library/Symfony/Component/Yaml. These usually come as submodule dependencies in the Doctrine libraries but you can also get them from their github pages
Console
Yaml
Remove the bootstrap('Config') call from the doctrine.php script. Don't know what Guilherme was thinking there :-)
That's it, from there it should work as expected.