I'm running some JUnit5 tests in Jenkins, using a freestyle job and a Jenkins pipeline. These tests run fine using gradlew locally.
The pipeline groovy script (Jenkinsfile) uses
sh './gradlew clean test'
The code checks out fine and I see the Welcome to Gradle 5.5.1! message
Then, all of the tests which run fine locally with gradlew clean test fail with:
15:50:22
uk.co.motests.mfldirect.tests.UploadDataTest >
dropDownsAreDisplayed() FAILED
15:50:22 java.lang.IllegalStateException
Any idea where / how to start debugging this? This is literally the first time I've tried to run using a groovy pipeline script.
I'm posting this in the hope there is a common, beginners mistake that crops up frequently. I can post further details of the groovy file if required.
To print tests' stdout and stacktrace, enable Gradle INFO logging with sh './gradlew clean test -i'
To view DEBUG logging use sh './gradlew clean test -d'
All this data is already present in ./build/test-results/test/*.xml so you could browse the workspace of the failed Jenkins job.
Related
I am trying to run a job through DSL script in jenkins. I am new to jenkins. Basically I want to run maven command to run my tests.
How to run maven command using DSL scripts.
Command: mvn test -Dcucumber.options="--tags #registration"
Here is the DSL scripts.But getting error.
I have Jenkins building my C# .NET Core api project. I added some xUnit tests and included a powershell script inside of my Jenkins build with the "dotnet test" command to execute the tests.
That all works well and the tests are run and i can see the output in the Jenkins console.
The problem is that if i have failing tests nothing happens - jenkins goes merrily along and finished up the build process and reports it as a success.
How can i get it to fail the build?
Is there a response from the 'dotnet test' command?
I know there are xUnit Jenkins plugins but they all seem to revolve around "display the results of xUnit tests". Which is not really what i am after. I want to ACT on the results of the tests, not just see them in fancy html.
You should check for the return code from dotnet test command. It returns 0 if all tests were successful and 1 if any of the tests failed. Unfortunately it's not documented but was confirmed in this issue
Trying to use the nifty Jenkins Pipeline, I had problems finding out how to publish NUnit test results.
I am able to run the tests by specifying the following command in the pipeline script:
stage 'Test'
bat '"C:\\Program Files (x86)\\NUnit 2.6.4\\bin\\nunit-console-x86.exe" "ProjectName\\bin\\Release\\UnitTests.net.dll"'
But how to make Jenkins "publish" the test results is not obvious. The Snippet Generator only suggests junit, and that does not seem to work.
I used nunit plugin version 0.21 and was able to publish results using
stage("PublishTestReport"){
nunit testResultsPattern: 'TestResult.xml'
}
(TestResult.xml is at the root of jenkins workspace in this above example)
Investigating the NUnit plugin for Jenkins led me on to this issue, where I found the solution:
step([$class: 'NUnitPublisher', testResultsPattern: 'TestResult.xml', debug: false,
keepJUnitReports: true, skipJUnitArchiver:false, failIfNoResults: true])
Adding this to the pipeline script worked for me!
However, it seemed the following should also work (but at the present, apparently, it does not): Using the Snippet Generator, select this:
step: General Build Step
Publish NUnit test result report
This generates the following in the Pipeline script:
step <object of type hudson.plugins.nunit.NUnitPublisher>
This fails!
I need some help in integrating protractor code with Jenkins. I am new to Jenkins so i am not sure if Jenkins or Cruise Control is right as currently we have builds in Cruise Control but we are okay to migrate to Jenkins if that is better. Can someone please help me with any tutorials to link my protractor task with Jenkins or Cruise Control?
Currently we are using Gulp as a wrapper over Javascript code for execution.
We are running it with command Gulp test --site folder name
Should i just specify this command in Execute shell script option of Jenkins?
Yes, running Protractor tests from any CI tool is not complicated
Step 1:Just configure your cruise control/Jenkins job with "Execute Shell" as build step
Step 2: Depending on your choice of running tests .. create a bat file
echo Protractor Execution
Protractor protractor.conf.js // In case running with protractor
npm run --e2etests // In case running with npm run config in package.json
Gulp test --site folder name // In your case
echo Over and out.
Step 3: Point your job build step to trigger the batch file
I got this one worked out. It is working fine when i enter protractor command in Jenkins directly.
I am having some issues with gulp command in jenkins but i will open a seperate thread on that.
I have a jenkins pipeline that builds a java artifact,
copies it to a directory and then attempts to execute a external script.
I am using this syntax within the pipeline script to execute the external script
dir('/opt/script-directory') {
sh './run.sh'
}
The script is just a simple docker build script, but the build will fail
with this exception:
java.io.IOException: Failed to mkdirs: /opt/script-directory#tmp/durable-ae56483c
The error is confusing because the script does not create any directories. It is just building a docker image and placing the freshly built java artifact in that image.
If I create a different job in jenkins that executes the external script as
its only build step and then call that job from my pipeline script using this syntax:
build 'docker test build'
everything works fine, the script executes within the other job and the pipeline
continues as expected.
Is this the only way to execute a script that is external to the workspace?
What am I doing wrong with my attempt at executing the script from within
the pipeline script?
The issue is that the jenkins user (or whatever the user is that runs the Jenkins slave process) does not have write permission on /opt and the sh step wants to create the script-directory#tmp/durable-ae56483c sub-directory there.
Either remove the dir block and use the absolute path to the script:
sh '/opt/script-directory/run.sh'
or give write permission to jenkins user to folder /opt (not preferred for security reasons)
Looks like a bug in Jenkins, durable directories are meant to store recovery information e.g. before executing an external script using sh.
For now all you can do is make sure that /opt/script-directory has +r +w and +x set for jenkins user.
Another workaround would be not to change the current directory, just execute sh with it:
sh '/opt/script-directory/run.sh'
I had a similar concern when trying to execute a script in a Jenkins pipeline using a Jenkinsfile.
I was trying to run a script restart_rb.sh with sudo.
To run it I specified the present working directory ($PWD):
sh 'sudo sh $PWD/restart_rb.sh'