I have created a new application using Entity Framework 4.3 database migrations. The migrations work great from the package manager console using the "update-database" command.
Now I want to run the database migrations every time the application is built using Team City, it looks like I need to create a powershell script that will do this.
Can anyone point me to some instructions on how to get the package manager commands to run from the command line, or powershell? All I can find is instructions on how to do this via the package manager console, which I don't know how to run from a Team City build step.
migrate.exe is what I was looking for, it is found in "packages\EntityFramework.4.3.1\tools".
Add a new build step in Team City using:
Runner type: command line
Command executable: packages\EntityFramework.4.3.1\tools\migrate.exe
Command parameters: MyApplicationName /StartupDirectory:MyApplicationName\bin
Install Entity Framework nuget to the repo and use the accompanying migrate.exe under packages\EntityFramework.5.0.0\tools\ or equivalent.
Then run a batch script like this:
SET AssemblyName=MyMvc4App
SET StartUpDirectory=MyMvc4App\bin\
SET ConnectionString=Server=tcp:XXXX.database.windows.net,1433;Database=XXXX;User ID=XXXX;Password=XXXX;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;MultipleActiveResultSets=True
SET ConnectionStringProvider=System.Data.SqlClient
SET ConfigFilePath=%CD%\MyMvc4App\web.config
SET MigrateExe=packages\EntityFramework.5.0.0\tools\migrate.exe
%MigrateExe% %AssemblyName%.dll /startUpDirectory:%StartUpDirectory% /startUpConfigurationFile:"%ConfigFilePath%" /connectionProviderName:"%ConnectionStringProvider%" /connectionString:"%ConnectionString%" /verbose
pause
I answered a similar question and there I explain why I have yet to get it working without specifying a web/app.config file.
Related
I have started to use version control in RStudio using GitLab, but now I wish to use GitHub instead. So, I need to move all of my repositories from GitLab to GitHub, as specified e.g. here.
But, for some time, I was using both GitHub and GitLab simulteneously, and developing single project on both repos individually! Quite stupid, but it happens..
Shortly, now I need know, which repo (GitHub or GitLab) is my R studio using? I am looking for some code that will print out the http of the repository in use?
something like repo.print and will return the http associated: https://gitlab.com/xx/yy/z or https://github.com/xx/yy/z.
git config --get remote.origin.url in Terminal or
shell("git config --get remote.origin.url")
in R console / script.
I'm currently an undergraduate researcher and I've been tasked with researching knowledge defined networking. The research in particular deals with very advanced code that's way beyond my minimal knowledge of omnet. The first instruction to build the network is to run the makefile (found here: https://bpaste.net/show/d26a592a563a) to generate the "networkRL" needed by the python script.
I've imported all of the files needed for the simulation but whenever I try to run the makefile I get an error:
"Error starting process.
Cannot run program "C:\Users\Sierra\DRL\omnet\router\makefile": Launching failed"
Or when I try to run the entire simulation it asks:
"Enter parameter 'NetworkAll.node0.tcontroller.folderName':"
I'm not sure if these are simple problems to solve and I'm just inexperienced, but any help would be greatly appreciated. I can post all of the source, ned, and header files if necessary. I didn't want to pack this entire post with 15+ code links if the makefile was the only one needed to solve this issue.
I'm using OMNeT version 4.6 on Windows 10 if that information is relevant
The term "run the makefile" means: run make in the directory where makefile is located. In OMNeT++ one can do this in two ways.
First way:
Open mingwenv.cmd from OMNeT++ main directory.
In the mingw console go to main directory of the project, for example:
cd /C/Users/Sierra/DRL/
In the mingw console type:
make
Second way:
In OMNeT++ choose File | Import.. |Existing Project into Workspace and select the project.
Build the project choosing Project | Build Project.
According the second error: open omnetpp.ini and set value for folderName parameter, for example:
**.folderName = "/c/some/directory"
or
**.node0.tcontroller.folderName = "/c/some/directory"
I want to remove a mock created using Pholio in Phabricator.
I have found a way to delete projects or tasks described in this answer, but cant figure out how to delete a mock.
The url of my mock is mydomain/M1 so I tried to execute the command
./phabricator/bin/remove destroy M1
but the output of the command was "No such file or directory"
Any help would be appreciated
That error indicates you are not running the command from the correct directory. When I run my destroy command, I browse to the location I have installed Phabricator to and run the command ./bin/remove destroy ...
On windows after running the grunt build command for creating brackets shell it gives done without errors but i dont see any .exe file generated..
What might be the problem???
Here are some possible solutions:
Are you following the full brackets-shell build instructions, including all prerequisites?
Make sure Brackets isn't running at the same time. The build will fail silently if the .exe file is currently in use (see bug).
Try with a fresh git clone of the repo. If your brackets-shell local copy has been around for a while, sometimes the build & deps folders can get in a bad state. (I'm assuming you haven't modified the source at all. If you have, try with an unmodified copy of the source first to make sure it builds correctly without any of your changes).
Check that python --version shows 2.7.x
Verbose build output would also be helpful in diagnosing issues like this, but unfortunately there's not yet an easy way to get that...
If you follow the instructions on bracket-shell's wiki page, the Windows executable should be created in the Release directory.
I'm running a Capifony deployment. However, I notice that Capifony's in-built commands are running against the previous release, whereas my custom commands are correctly targeting the current release.
For example, if I run cap -d staging deploy, I see some commands output like this (linebreaks added):
--> Updating Composer.......................................
Preparing to execute command: "sh -c 'cd /home/myproj/releases/20130924144349 &&
php composer.phar self-update'"
Execute ([Yes], No, Abort) ? |y|
You'll see that this is referring to my previous release - from 2013.
I also see commands referring to this new release's folder (from 2014):
--> Running migrations......................................
Preparing to execute command: "/home/myproj/releases/20140219150009/
app/console doctrine:migrations:migrate --no-interaction"
Execute ([Yes], No, Abort) ? |y|
In my commands, I use the #{release_path} variable, whereas looking at Capifony's code, it's using #{latest_release}. But obviously I can't change Capifony's code.
This issue against Capistrano talks about something similar, but I don't think it really helps, as again I can't change Capifony's code.
If I delete my releases folder on the server, I have a similar problem - #{latest_release} doesn't have any value, so it attempts to do things like create a folder /app/cache (since the code is something like mkdir -p #{latest_release}/app/cache).
(Assuming I don't delete the current symlink and the release folder, the specific error I see is when it fails to copy vendors: cp: cannot copy a directory, /home/myproj/current/vendor, into itself. However, this is just the symptom of the bigger problem - if it thinks the new release is actually the previous one, that explains why current also points there!)
Any ideas? I'm happy to provide extracts from my deploy.rb or staging.rb (I'm using the multistage extension) but didn't just want to dump in the whole thing, so let me know what you're interested in! Thanks
I finally got to the bottom of this one!
I had a step set to run before deployment:
before "deploy", "maintenance:enable"
This maintenance step (correctly) sets up maintenance mode on the existing site (in the example above, my 2013 one).
However, the maintenance task was referring to the previous release by using the latest_release variable. Since the step was running before deployment, latest_release did indeed refer to the 2013 release. However, once latest_release has been used, its value is set for the rest of the deployment run - so it remained set to the 2013 release!
I therefore resolved this by changing the maintenance code so that it didn't use the latest_release variable. I used current_release instead (which doesn't seem to have this side-effect). However, another approach would be to define your own variable which gets its value in the same way as latest_release would:
set :prev_release, exists?(:deploy_timestamped) ? release_path : current_release
I worked out how latest_release was being set by looking in the Capistrano code. In my environment, I could find this by doing bundle show capistrano (since it was installed with bundler), but the approach will differ for other setups.
Although the reason for my problem was quite specific, my approach may help others: I created an entirely vanilla deployment following the Capifony instructions and gradually added in features from my old deployment until it broke!