I have running intellij with cucumber scenarios.
Now I want to start a specific scenario from outside intellij.
Is there a possibility e.g. from a shell or a java programm to excecute something in intellij?
Is there a possibility to use a currently running intellij instance for that?
Thanks
Jochen
you did not provide many info, but I bet if you use Maven you can run from a terminal / git bash etc your tests outside IDE, e.g.:
mvn test
See more info here: Run Cucucmber from terminal
Related
I am able to successfully run shell scripts and create and configure shell script run configurations in IntelliJ. However, I can't set breakpoints. When I try to put a breakpoint in the gutter or elsewhere as with regular Java debugging, no breakpoint appears. Has anyone had success with this, and if so how?
I'm using IntelliJ 2018.3.6 Community Edition.
Shell script debugging is supported only by the paid BashSupport Pro plug-in. You would also need the latest IntelliJ IDEA version to use it.
BashSupport Pro adds advanced features for shell scripts to your
JetBrains IDE. You can debug Bash scripts, run bats-core tests and
work efficiently with shell scripts.
Lets say I have run-config1 and run-config2 setup for my project in IntelliJ.
I know there are ways of adding custom shell code to be perfomed before/after a build run, but that's not what I want to do.
Is there a way of calling them from the embedded terminal?
As of IntelliJ IDEA 14 there is no such way. You can write a plugin for IntelliJ IDEA that will handle a command like "idea.sh run configuration-name" and start the run configuration in the existing instance, but this is fairly non-trivial.
Does anyone know how I can skip JUnit tests in IntelliJ when doing a Gradle build like the following command line version? I have searched extensively for a solution but can't find one. I am in the process of converting an existing project to Gradle and need to support many developers that are not familiar with Gradle, some UX, some front end, and some Java. There are many broken Junit tests in the myriad modules and long-term we will fix them. Short term I need all other developers to use the tools they are familiar with to be able to do their job easily.
./gradlew build -x test
The Gradle-Android Compiler settings allow for command-line options but not non-android projects as shown in the IntelliJ settings dialog shown below.
You should be able to run a standard clean build from intellij if it's a gradle project (aka gradle integration in intellij). Then edit the configuration and add at the script parameters : -x test which will run the clean build (or any other task) without running tests.
I am using Intellij IDEA 2019.3 (Community Edition).
You can skip test using following settings.
You can get to this via Gradle panel located at right top corner.
Select task -> Run Configuration -> Right click -> Edit Run Configuration..
From intellij 2021.2 onwards, type the argument directly in Run text
I am looking for ideas for a Play 2.0 continuous integration setup. It would contain typical jobs like build after a git push, nightly builds with deployment to a test Heroku instance etc. Also code quality and test coverage metrics generation would be handy.
At the moment the stack looks like Play 2.0 with Java but that might change to Scala.
For "traditional" Java web app I would use Hudson/Jenkins. I found a Hudson plugin for Play but it doesn't seem to support Play 2.0. Is Hudson suitable tool here in general or what is your setup for Play 2.0 applications?
Play 2.0's build tool is just a thin wrapper around SBT. You should be able to use Hudson's sbt plugin to execute SBT build commands that are the equivalent of the Play commands you would execute from the console.
We execute the following under Bamboo for our builds:
SBT_OPTS="-Dsbt.log.noformat=true"
sbt clean compile test
(The SBT_OPTS variable turns off the colour formatting, making test output legible in log files.)
I found useful to add JUnit reporting plugin as I couldn't get test results to be displayed otherwise.
https://github.com/bseibel/sbt-simple-junit-xml-reporter-plugin
For PMD and Checkstyle I used this:
https://github.com/ymasory/sbt-code-quality.g8
For test coverage I am using JaCoCo at the moment:
http://ronalleva.com/2012/04/25/jacoco-and-play.html
Scct could be other option for coverage: http://mtkopone.github.com/scct/
With those and PMD, CheckStyle and JaCoCo plugins for Jenkins I have now quite ok setup for a Play 2 Java project.
here Is some detailed tutorial about doing It
http://wiki.cloudbees.com/bin/view/DEV/Playframework
It based on cloudbees but it would work fro any Jenkins Installation
You actually don't even need to use the SBT Plugin. I am running Play 2.1.1 on Jenkins and simply use the Execute Shell. I run something like the following:
cd ./your-play-project-root
play clean compile test stage
exit
This works quite well. "play" is simply just a thin wrapper around sbt.
"stage" will create a runnable in your target/server directory. Then, you can simply shell again to actually start your play application!
I've tried in each and every way to test a grails-app using hudson. I've tried testing with maven, I've tried testing with the grails plugin and I've tried testing with a shell builder it seems that building via shell is the only thing that works..
Every time I get the same error:
org.hibernate.HibernateException:
contains is not valid without active
transaction
But If i go to a shell and type
grails test-app
everything runs fine.
Does anyone have any idea on what's going on?
I'm using CentOS with Java 1.6, no slaves, just a simple hudson deploy over Tomcat6.
I've tried both with maven and grails builder, both fail.
Edit: it seems that if I run both unit and integration tests on the same command (either with grails or with mvn) the integration tests fail always.
Hudson/Jenkins usually just use the command line for executing grails plugins (You should be able to confirm that from the build output). You could probably add a pre build step to dump the environment, so you can see if anything there (or in your own shell) cause it to be fundamentally different.
Otherwise try to log in as the hudson user and find the hudson workspace and repeat the process manually. That has been the easiest way to debug hard problems like this..
regards