After the build is passed for source code, some .jar files are created.
Those jar files have to be put in specific path before triggering relevant testcases in Jenkins.
In a short,
How to configure/set up the test cases after the successful build and before triggering them in Jenkins?
Have 1 job to build your code.
Add a post exec command to this job to move the jar files to the correct path
After this build job is finished have it trigger a second job that does only the tests.
Related
I have separated my build tasks in several jobs. The following is a simplified structure.
The basic jobs are:
compile
quick-tests
full-tests-part-1
full-tests-part-2
Additional jobs are:
full-tests
full-build
Each job is configured to accept a workspace parameter to allow all jobs to be executed on the same code (workspace). This is passed from any calling job. Besides, all jobs are running on a slave node.
Job full-tests is configured to bundle the "full tests". Therefore it uses the build step Trigger/call builds on other projects with projects full-tests-part-1, full-tests-part-2.
Job full-build is configured to bundle the build pipeline. Therefore it uses the build step Trigger/call builds on other projects with projects compile, full-tests.
Job compile checks out the Git repository and compiles the code. Afterwards it starts the quick tests. Therfore it uses the post build action Trigger parametrized build on other projects with project quick-tests.
All compilation and test runs are triggered by Ant scripts.
When I trigger the full-build job, the following job sequence results:
full-build
compile (triggers quick-tests)
full-tests
full-tests-part-1
full-tests-part-2
quick-tests
The problem is, that the "full tests" are failing, whereas compile and quick-tests succeed. Both, the full and the quick tests, use the same build.xml in the same workspace, but the "full tests" complains.
Quick tests:
Buildfile: J:\jenkins-slave\workspace\full-build\272\project-path\build.xml
Full tests:
ERROR: Unable to find build script at J:\jenkins-slave\workspace\full-build\272\project-path\build.xml
Does anyone know whether there is a difference in "seeing" the workspace files depending on whether the job is part of the build (triggered as build step) or not (triggered as post build action).
If anything is unclear, please let me know.
I have two runners file in my cucumber framework, 1. The main runner.java which executes all of my feature files and 2. FailedRunner which only needs to be triggered when the first runner reports any failures.
Now the current execution method I am using is
gradle clean build -Denv=QA -Dcucumber.filter.tags=#QA
Now, I would Also like to pass my runner file name so that, I can create a upstream/downstream job to run the failedRunner class for retries for MainRunner file.
Thanks
When i run Jenkins Jobs that runs DSL script as a built step to generate folder in jnkins it shows unreferenced Items which contains the job details of previously build of the same job. Is there aby way to get rid of the Unreference Item
DSL Script :
folder('project-e') {
displayName('project-e')
description('Folder for project e')
}
Console output :
Processing provided DSL script
Added items:
GeneratedJob{name='project-e'}
Unreferenced items:
GeneratedJob{name='project-b'}
No, you can not get rid of the unreference items output. But you can ignore it if you set "Action for removed jobs" to "Ignore" in the "Process Job DSLs" build step.
Job DSL scripts are not meant to be one-time generator scripts. A script should describe a part of your Jenkins configuration. If you want to add a folder, you add a folder to the script. If you want to delete a folder, you delete the folder from the script. Then you run the Job DSL seed job to apply the changes.
I have an npm script that basically executes some unit tests with Jest and then generates a test-results.xml file in a dist/ folder. This is executed within a deploy.sh script that basically has a npm run test line in it that kicks off the test task.
When Jenkins runs my code, however, I can see that the tests are passing in the Jenkins console, but for some reason Jenkins can't see the test-results.xml file in the workspace. Hence, I get this error:
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?
It's weird because I SSH'd into my server and can clearly see that my test script generated a test-results.xml file under dist/ folder, but for some reason the entire dist/ folder and everything in it is conspicuously absent from my Jenkins workspace.
This question was resolved in question comments, but for future reference and other in similar situations:
Make sure that you are looking at the same place as Jenkins is. Jenkins always resolves the pattern provided in the Public JUnit test result report relative the workspace root.
For freestyle jobs or node steps in pipeline jobs, the location of the workspace root is printed on the console output, look for:
Building in workspace <jenkins_root>\workspace\<job_name>
or
Building remotely on Agent42 in workspace <path_to_workspaces>/workspace/<job_name>
Is it possible to run a Nant script as a Jenkins post build action?
I get the option to run a script as a Build Step but not as a build action. Is there any particular plugin which enables this option.
The reason I am looking for this functionality is that I need to run a script which depends on the ArtifactDeployer post build action. If i specify the code in the build step it gets executed before the ArtifactDeployer and the build fails
You can use the Post Build Task Plugin
edit
One way of getting the build number if it's not working with this plugin is using the Groovy Post Build Plugin
With it you can execute groovy code as a post build action, get the build number and execute NAnt
the build number is accessible from the following property
manager.build.number
Post-build Actions -> Execute a set of script run after a build when it succeeds or fails. My experience shows that it only sometimes runs when a build is aborted.
As advised above, the Post-build Actions -> Post build task (via the named post task plug in) is always evaluated for run (regardless of the build exit status). Additional setting via phrase in the log ("Build was aborted") works reliable for me.
My problem was to run something even on an aborted build and post build task sorted out this problem.