Context
The default "Command" for running a rust test in CLion is:
test --package ... --lib ... -- --exact
(This is generated by pressing a green triangle on a specific test method)
Problem
I'd like to be able to change the default to include the -r flag for running in release mode.
This would allow me to forego having to edit each generated configuration every time I run a new test.
Question
Is this possible, if so how?
Related
I'm trying to use Xdebug (v3) through PhpStorm (v2022.3.2) to debug a PHPUnit test method from inside a Docker container.
Xdebug is correctly setup and also the server in PhpStorm is.
In fact, if I run tests from command line, Xdebug stops at breakpoints:
XDEBUG_SESSION=1 PHP_IDE_CONFIG="serverName=myapp.localhost" vendor/bin/phpunit --testdox --filter testProfileUpdate
If I debug the test clicking on the "bug" icon on the left of the test method, instead, I receive the following error:
Connection was not established. Probably 'xdebug.remote_host=host.docker.internal' is incorrect. Change 'xdebug.remote_host'.
Looking at the command executed by PhpStorm to debug a test method, here is what I see:
[docker://myapp:latest/]:php -dxdebug.mode=debug -dxdebug.client_port=9000 -dxdebug.client_host=host.docker.internal /opt/project/vendor/phpunit/phpunit/phpunit --configuration /opt/project/phpunit.xml --filter "/(ProfileTest::testProfileUpdate)( .*)?$/" --test-suffix ProfileTest.php /opt/project/tests --teamcity
Tried to configure two more flags
I've also tried to configure two more flags:
-dxdebug.idekey="serverName=myapp.localhost"
-dxdebug.session=1
The resulting command is this:
[docker://myapp:latest/]:php -dxdebug.mode=debug -dxdebug.client_port=9000 -dxdebug.client_host=host.docker.internal -dxdebug.idekey="serverName=myapp.localhost" -dxdebug.session=1 /opt/project/vendor/phpunit/phpunit/phpunit --configuration /opt/project/phpunit.xml --filter "/(ProfileTest::testProfileUpdate)( .*)?$/" --test-suffix ProfileTest.php /opt/project/tests --teamcity
Also with this configuration, Xdebug doesn't start and breakpoints are ignored (and the error message pops up).
Tried to disable params passed by PhpStorm
I tried to disable params passed automatically by PhpStorm going to Settings > PHP > Debug.
Then, in the section "Advanced settings" I unflagged the option "Pass required configuration options through command line".
Now, the resulting command is this:
[docker://myapp:latest/]:php /opt/project/vendor/phpunit/phpunit/phpunit --configuration /opt/project/phpunit.xml --filter "/(ProfileTest::testProfileUpdate)( .*)?$/" --test-suffix ProfileTest.php /opt/project/tests --teamcity
As you can see, there is no mention of xdebug.client_host nor of xdebug.remote_host.
Nevertheless, PhpStorm continues to pop up the same error mentioning xdebug.remote_host=host.docker.internal.
I imagined that an error should have occurred, but different, something saying a required parameter is missed.
Request for help
Any idea about how to configure PhpStorm to start an Xdebug session to debug a PHPUnit test?
-dxdebug.client_port=9000
Xdebug 3 now uses 9003 port by default instead of 9000. Try sticking to this.
In PhpStorm you most likely have both ports listed (9000,9003 as a default value, to cover new and old Xdebug versions) and it uses the first one for CLI scripts (which PHPUnit is). Either remove it (preferred; so you will only have 9003 there) or make it last (i.e. 9003,9000).
-dxdebug.idekey="serverName=myapp.localhost"
This will not work (wrong approach). You are trying to pass it as Xdebug IDEKey param... but it actually should be the value of the ENV variable named PHP_IDE_CONFIG.
If you want to actually use it:
Look into the PHPUnit config file: it has the ability to set up custom ENV variables for tests.
Another place: PhpStorm's Run/Debug Configuration for PHPUnit has an Environment variables field: try using it for this purpose.
Or use it in your actual docker file/config.
Other than that: enable Xdebug log (xdebug.log), try to debug (both when it's working and when it's not) and see what the log has to say for both runs (where it connects to, what the response is etc). You should spot the difference that should give the clues on what might be wrong (in which direction to dig further).
This actually should be the first step when investigating "why it works here and not there" situations.
I use PhpStorm in development. To run a test I do below 3 commands:
docker-compose exec app bash
cd app/
vendor/bin/phpunit unitTest/Sample.php
I want to be able to run the test just by clicking the "Run" button inside PhpStorm.
I tried to accomplish it using docs from IntelliJ but they overwhelmed me.
I thought I just need to change the interpreter path but couldn't understand how to attach to a running docker.
First you need to add your Docker-compose based interpreter. See this guide.
Second, add a PHPUnit configuration based on this interpreter, see "Integrate PHPUnit with a PhpStorm project".
After that you should be able to simply Run the tests using IDE UI.
I am wondering how to
1) how to run model directly in Eclipse without GUI - just run the model like run other java codes in Eclipse and print out something i am interested.
2) how to run it in headless mode without even Eclipse - I plan to deploy my model in a remote server, which the server or my own PC could run the model automatically at a specific time of the day.
3) Every time when I change the code, I have to launch a new GUI in order to reflect the code changes. It takes at least 5 seconds to open the GUI. This is very inefficient way of model development and debugging. What is the better strategy available?
For headless, or batch, running of models, take a look at the Repast Batch Getting Started Guide. This can either allow you to run multiple runs without a GUI, as in (1), or if you look at section 9.2, it will allow you to run from the command line without invoking Eclipse, as in your case (2). If you want more control, I'd suggest looking at the InstanceRunner class and utilize the complete_model.jar payload that is generated by the Batch GUI or batch_runner.jar.
Unarchive the complete_model.jar
Then use the InstanceRunner class from the command line, like so from within the complete_model directory
java -Xmx512m -cp "../lib/*" repast.simphony.batch.InstanceRunner \
-pxml ../scenario.rs/batch_params.xml \
-scenario ../scenario.rs \
-id $instance \
-pinput localParamFile.txt
where the localParamFile.txt is an unrolled parameter file specifying the combination(s) of parameters to run (see the unrolledParamFile.txt within the payload for an example) and if you're running just one instance this would just be one line.
I've got an ant target ant server that runs a Java application which logs to the console. I need to run a new ant target ant server-gui which also logs to the console. But when I run ant server the logging prevents me from running any new ant targets.
When I enter ^c (which is the only way I know of to get out of situations like that) it kills the Java application. I need both to run. What keystroke will get me out of that "input" mode and able to run new terminal commands?
UPDATE: I haven't found a direct solution to getting out of that mode I mentioned, but opening a new tab/window in terminal does the trick. I can run as many any commands as I'd like that way. Still looking for a good solution to get out the "input" mode, though!
UPDATE 2: #abcdef pointed out another post that has an even more elegant solution.
There are a few ways to do this, assuming you are on *nix
1) Run the ant command with a & at the end to tell *nix to run the command in the background
2) Run the command with nohup at the beginning (https://en.wikipedia.org/wiki/Nohup)
3) when the process is running press ctrl-z then enter the command bg. This manually forces the command to run in the background
I hope this helps you out
I want to use a Dockerfile to build an image. However, commands will need user input as they run. Currently, the build is not successful because docker exits on user input. I know I can use the -i -t options on docker run command but I want to do that on a Dockerfile. How is that possible?
You can try with expect or a similar tool.
The easiest way to configure it is using the autoexpect tool, which lets you run the commands interactively and creates an expect script for you.
I couldn't get the rvmsudo stuff working (I haven't used it and didn't want to spend too much time with it) so I decided to use vi instead. First run autoexpect
$ autoexpect vi test
This will open vi and you can create or edit the file and save it. After exiting the vi you'll see your file test as well as an expect script script.exp.
You can then remove the test file and execute script.exp. It will recreate the same file using the same steps.
The autoexpect tool is great, but you may have to create a script from scratch if you need to have more control over what happens. E.g. if you don't want the script to work with the exact expected input.