Can anyone tell the meaning of "dry run" in Doctrine 2? I am not able to find it on Google.
I can only get some information by using this command
php app/console doctrine:migrations:migrate --help
which outputs
--dry-run Execute the migration as a dry run.
Dry run in the context of an console command means to run all actions for gathering informations, you get all verbose output, which will be executed, but nothing is really executed. So you can see, what the command will do, but can be safe, your database won't be modified.
If you are try latest version of symfony3
php bin/console doctrine:schema:update --dump-sql
you can find exact changes are deployed in database -
if you okay with changes run following command in console -
php bin/console doctrine:schema:update --force
Related
Trying to add appcenter CLI commands for example: appcenter test run espresso --app "Test-apps" --devices "google-pixel-2-android-10" --app-path pathToFile.apk --test-series "master" --locale "en_US" --build-dir pathToEspressoBuildFolder
But where should add this CLI command & how to add it stepwise. Can anyone explain clearly?
Your question is still not very clear, it would be great if you copy and paste the errors you are getting, share a screenshot or give more details. Tell us what OS you are using, where did you get this command from?
You need to open the terminal or shell, and paste the commands in there.
There are a few pre-requisites though, the documentation is not super beginner friendly.
From the docs:
Install NodeJS https://nodejs.org/en/
In the terminal, run npm install -g appcenter-cli
I am trying to execute drush commands through a crontab for a Drupal 8 site. These commands work when I call them directly, but when run through my user's crontab I get the following error:
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be
called with a real container.
Other posts suggest this is a bug within older versions of Drush, but I am on 10.3.5.
I have tried a number of things over the past few hours including reconfiguring cron, but ultimately it seems Drush is not bootstrapping Drupal correctly, but I need to be able to run the queue from cron
This is a test command I'm running which just adds to the Drupal log...
crontab (my user)
* * * * * /var/www/html/vendor/bin/drush scr /var/www/html/scripts/what.php -r /var/www/html/web
what.php
<?php
\Drupal::logger('mymod')->info("CHECKING IN FROM CRON CLI...");
Here is another command, closer to what I'm trying to accomplish...
crontab (my user)
* * * * * /var/www/html/vendor/bin/drush queue:run commerce_recurring -r /var/www/html/web >> /var/www/html/private/logs/cron_commerce_recurring.log
The error I get here is:
Command queue:run was not found. Drush was unable to query the database. As
a result, many commands are unavailable. Re-run your command with --debug
to see relevant log messages.
I get this same error when running this command with drupal console.
Any suggestions appreciated.
Thanks.
This turned out to be a database connectivity issue. The tricky part was getting to the error. I had to install an MTA, so that cron could write errors to my local user's mailbox and then add the --debug option, so that I could see the real error.
I'm working on a DDEV instance and for some reason the DDEV settings were not being loaded. An issue for another day...
I need to update /etc/hosts for all instances in my EMR cluster (EMR AMI 4.3).
The whole script is nothing more than:
#!/bin/bash
echo -e 'ip1 uri1' >> /etc/hosts
echo -e 'ip2 uri2' >> /etc/hosts
...
This script needs to run as sudo or it fails.
From here: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html#bootstrapUses
Bootstrap actions execute as the Hadoop user by default. You can execute a bootstrap action with root privileges by using sudo.
Great news... but I can't figure out how to do this, and I can't find an example.
I've tried a bunch of things... including...
running as Hadoop and adding 'sudo' to each of the 'echo' statements in the script
using a shell script to copy and chmod the above ('echo' statements with no 'sudo') and running local copy using run-if bootstrap that calls 1=1 sudo bash /home/hadoop/myDir/myScript.sh
hard coding the whole script as a one-liner into a run-if bootstrap action
I consistently get:
On the master instance (i-xxx), bootstrap action 2 returned a non-zero return code
If i check the logs for the "Setup hadoop debugging" step, there's nothing there.
From here: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-overview.html#emr-overview-cluster-lifecycle
summary emr setup (in order):
provisions ec2 instances
runs bootstrap actions
installs native applications... like hadoop, spark, etc.
So it seems like there's some risk that since I'm mucking around as user Hadoop before hadoop is installed, I could be messing something up there, but I can't imagine what.
I think it must be that my script isn't running as 'sudo' and it's failing to update /etc/hosts.
My question... how can I use bootstrap actions (or something else) on EMR to run a simple shell script as sudo? ...specifically to update /etc/hosts?
I've not had problems using sudo from within a shell script run as an EMR bootstrap action, so it should work. You can test that it works with a simple script that simply does "sudo ls /root".
Your script is trying to append to /etc/hosts by redirecting stdout with:
sudo echo -e 'ip1 uri1' >> /etc/hosts
The problem here is that while the echo is run with sudo, the redirection (>>) is not. It's run by the underlying hadoop user, who does not have permission to write to /etc/hosts. The fix is:
sudo sh -c 'echo -e "ip1 uri1" >> /etc/hosts'
This runs the entire command, including the stdout redirection, in a shell with sudo.
In AWS Device Farm, I created a new run. I chose native application. I uploaded my APK. I chose Calabash as the tests. I got this error message:
Tests skipped due to test package parsing error. Please check Parsing result for more details.
I downloaded the Parsing result. Here's what it said:
Failed to run cucumber dry-run command. See the information below for more details.
Here are the contents for the Parsing result:
'cucumber --dry-run --format json --out /tmp/scratchvxnAeX.scratch/tmpF6f5Xx' failed.
Could not find proper version of cucumber (2.99.0) in any of the sources
Run `bundle install` to install missing gems.
Solution
I have some .rb page objects. I added require 'calabash-android' to the top of those files. Then I made a new run and ran it. It worked.
How I got to the solution
Through Google I came across CALABASH_TEST_PACKAGE_DRY_RUN_FAILED here.
Running this command failed: cucumber-ios --dry-run --format json features
I figured that was for ios. So I tried this: bundle exec calabash-android run .\app-releaseStaging.apk --dry-run. I got this error:
uninitialized constant Calabash::ABase (NameError)
I wasn't getting that error when running locally.
According to this:
-d, --dry-run Invokes formatters without executing the steps. This also omits the loading of your support/env.rb file if it exists.
I had require 'calabash-android' inside env.rb. So I moved it to my page objects. Then it worked.
You may find the aws-device-farm-calabash-tests-for-sample-app useful.
My dev environment on windows 8 has been running great but all of a sudden whenever i run:
php bin/console doctrine:schema:update --force --env=test
I get a very odd error message:
All other developers are working completely fine in our master branch. I've deleted the project from my local system and repulled it from git and ran through the composer install process but no luck. That leads me to believe the problem is on my pc and not the project code.
Any ideas?
Are you sure that you are not using a backwards slash like in your screenshot:
php bin\console doctrine:schema:update --force --env=test
This produces (for me) the error:
Could not open input file:...
But if instead you use this:
php bin/console doctrine:schema:update --force --env=test
it works correct, also in case that doesn't work, try doubling up the forward slash like so:
php bin//console doctrine:schema:update --force --env=test
Turns out the copy paste of the command contained a special character. So frustrating!