As doctrine migrations help says:
Or you can also execute the migration without a warning message which you need to interact with:
./bin/console doctrine:migrations:migrate --no-interaction
I try to run current migration version by command:
./bin/console doctrine:migrations:migrate current --no-interaction
Nevertheless, I always get an error:
WARNING! You have 1 previously executed migrations in the database that are not registered migrations.
>> 2020-01-29 13:03:03 (20200129130303)
No migrations to execute.
Of course, I clearly understand that "I have 1 previously executed migrations".
And It is my goal to execute a specific old version without any interaction. How can I achieve it?
That's not an error, that's just warning. It's displayed for the reasons #rkeet mentioned in comment. The command is still executed without interaction.
If you do not want to see any output, you should use --quiet, -q flag.
Interaction is when Symfony asks you Are you sure you want to execute migrations? (or whatever the messages are), and you answer with either y or n. This part is omitted with a --no-interaction flag.
Related
I want to be able to run a command and determine if there is a pending migration. This is going to be scripted so the best thing would be a command that returns easy to parse output.
The only command I could find for this is info but the output stinks. I want to confirm if there is a way to get parsable output.
For example this command:
flyway -locations="filesystem:schema_migration_files" \
-user="userxyz" \
-password="lsdkfklsdfjld" \
-url=jdbc:postgresql://myserver:5432/mydb \
info
Gives me this atrocious output:
I can parse that mess myself. I would probably just check if string "Pending" is in the output, but I'm not sure how reliable that would be. I just need to determine if there is or isn't a pending migration.
You can use the -outputType=json command line argument, and then parse the output.
I'm not working in Symfony, but pulled in symfony/var-dumper package via composer, and it works just fine when I do a simple test:
<?php
include 'vendor/autoload.php';
dump('Hello World of Dumping');
I see the output in the browser just fine.
Symfony docs for the VarDumper show that there is a "Dump Server", https://symfony.com/doc/current/components/var_dumper.html#the-dump-server , and this is really how I would like to do my dumps. The problem is, since I'm not using Symfony, I'm doing my best to figure out how I can use it. I did pull in the console package:
composer require symfony/console --dev
So, over in the terminal (ubuntu), I run this command:
./vendor/bin/var-dump-server
When I do that the terminal displays:
[OK] Server listening on tcp://127.0.0.1:9912
But when I run my test script and do some dumps, I don't see anything in the terminal. No change.
Even though that didn't work, what I really want to do is log to a file. If I try to run the command and specify HTML format and a file to dump in, it creates the file, but when I do a dump test nothing is put in the file:
./vendor/bin/var-dump-server --format=html > dump.html
Again, it just says that the server is listening.
Now, before you look at the docs and tell me I'm crazy, I know that the docs show the command as:
./bin/console server:dump
But I'm not using Symfony, and I'm assuming I'd have to be in order for that command to work. I could be wrong...
So, I'm looking for some help with my dump server problem. Perhaps the dump server feature can't be used outside of Symfony, but I'd like to know if that's true or not, and I don't see evidence of that in the docs. I hope you can help, because I don't know what else to do/try.
Symfony documentation is incomplete. There is no reference to it, even on the advanced usage page, but one needs to use the ServerDumper class. Something as simple as this gets the dump server working:
<?php
include 'vendor/autoload.php';
use Symfony\Component\VarDumper\VarDumper;
use Symfony\Component\VarDumper\Cloner\VarCloner;
use Symfony\Component\VarDumper\Dumper\ServerDumper;
VarDumper::setHandler(function ($var) {
$cloner = new VarCloner();
$dumper = new ServerDumper('tcp://127.0.0.1:9912');
$dumper->dump($cloner->cloneVar($var));
});
For getting dump data same as laravel you should install two composer packages as dev dependancy .
composer require --dev symfony/var-dumper
composer require --dev symfony/console
and inside your controller run below code
dump($anyVariable);
Then you will get dump output like below same as laravel
Environment : Hortonworks Sandbox HDP 2.2.4
Issue : Unable to run the hadoop commands present in the shell scripts as a root user. The oozie job is getting triggered as a root user, but when the hadoop fs or any mapreduce command is executed, then it runs as yarn user. As yarn, doesn’t have access to some of the file system , so the shell script is failing to execute. Let me know what changes I need to do , for making it run the hadoop commands as root user.
It is an expected behaviour to get Yarn in place whenever we are invoking shell actions in oozie. Yarn user only have the capabilities to run shell actions. One thing we can do is to give access permissions to Yarn on the file system.
This is more like a shell script question than an Oozie question. In theory, Oozie job runs as the user who submits the job. In a kerberos' env, the user is whoever signed in with keytab/password.
Once job is running on Hadoop cluster, in order to change the ownership of command, you can use "sudo" within your shell script. In your case, you may also want to make sure user "yarn" is allowed to sudo to the commands you want to execute.
Add below property to workflow:
HADOOP_USER_NAME=${wf:user()}
I have two separate console commands within Symfony that are both run as cron jobs. When these commands happen to run at the same time, however, they both want to clear / update the dev cache and this results in one command or the other failing with a PHP fatal error "Cannot redeclare class etc etc etc".
Apart from making sure these two commands run at different times and each clears the dev cache before they run, is there any way to prevent conflicts like this in Symfony console commands?
FWIW, we have tried forcing the environment to prod, but it still seems to want to use the dev cache (so this may end up being a different question altogether):
$ sudo php /var/www/prod/app/console console-command --env=prod orgs --report --do-sync --welcome
PHP Fatal error: Cannot redeclare class Monolog\Handler\FingersCrossedHandler in /var/www/prod/app/cache/dev/classes.php on line 3704
Edit: it turns out that some of our code was explicitly defining the dev environment, totally ignoring the CLI options. Apologies.
Could you try using something like a Makefile
both: make command-one make command-two
command-one:
app/console foo
command-two:
app/console bar
Then to run you could do
make both
or
make command-one
or
make command-two
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!