I was searching for a jenkins plugin to re-run only the failed tests for a specified number of times. Came across Flaky test handler plugin. But this plugin is only for maven projects.
Is there a similar plugin for ant projects?
Related
I am getting some issues with the configuration and setup jenkins to the local gradle project .it's some thing like integration of gradle with jenkins and jenkins will be responsible for building and running the gradle ...initially I tried with cmd execution available at jenkins but its not promising solution .So I feel I need some help for setup gradle plugin for local bild.gradle execution
I don't know which version of Jenkins you use, but with decently recent version you should have a build step type "Invoke Gradle Script" in "Freestyle project" project types, that you should use to execute your gradle build.
Everything is well explained here: https://guides.gradle.org/executing-gradle-builds-on-jenkins/#create_a_jenkins_job
I am using Jenkins pipeline scripts for all my jobs. I was using Promoted-builds plugin for other jobs, But its not compatible with Pipeline scripts. Is there any alternative? .
Pipeline script has manual input but that does not solve the problem as the job is in build queue until the input is provided.
I have been using Hudson / Jenkins since 2007. I have never found the Promoted Builds plugin to be that useful.
Instead I use labels / tags from different jobs (Build and Unit Test, System Test, Performance Test) or artifact repositories as markers of where an version or artifact has progressed to in the overall "pipeline".
Regarding Artifactory:
In my Build and Unit Test job, on Success of the Integration branch I tag the source code and upload the tested artifact to Artifactory.
In my System Test job, on success I call my Performance Test job as a downstream job passing the version number of the successfully tested package as a parameter.
In my Performance Test job, on success I "copy-promote" the tested artifact to the next designated location in Artifactory.
HTH
For GUI testautomation we have set up a Maven project using JBehave (v4.0.4) as a BDD framework. The stories are executed with a JUnitReportingRunner and run continously in a Jenkins (v1.630) master slave environment.
I recently noticed that in some cases, the Jenkins build is marked as successful despite some failed steps. The XUnit test report correctly indicates that there is a failed test while the Jenkins build does not. We haven't configured any thresholds concerning the build status. Therefore one failed test should cause the build to fail (and it does most of the time).
This problem is very annoying since we heavily rely on the Jenkins mail notifications. Any pointers on how to solve it are very much appreciated.
As per the recent announcement on Gradle forum, the Sonar Plugin and Sonar Runner Plugin are being deprecated in favor of the SonarQube plugin. Can someone share any links (documentation or blogs) that demonstrate setting this up in Jenkins. I tried this on the local setup and gradle sonarqube task works great.
Should we continue to use the "Invoke Standalone Sonar Analysis" (from Jenkins-Sonar plugin) build step in a freestyle Jenkins job? With the default settings, it doesn't infer mandatory information like sonar.projectKey, sonar.projectName, sonar.projectVersion, sonar.sources from the build.gradle file. To provide it manually for a multi-module project is painful (particularly for sonar.libraries and sonar.binaries). One could think to generate a sonar-project.properties file as part of a custom gradle task that will subsequently be used by the Standalone Sonar analysis step.
However, it seems that this a generic requirement and I feel that there might be a simpler way out in in the Jenkins-Sonar plugin. Could someone familiar with the Jenkins-Sonar Plugin shed some light on it?
System info:
Gradle 2.5
Jenkins 1.560
SonarQube 4.5
SonarQube Gradle Plugin 1.0
Sonar Runner 2.3
Jenkins Sonar Plugin 2.2
JDK 1.8
Linux 2.6
Thanks in advance!
EDIT:
I did not want to put the database username and password of the remote sonarqube instance in my gradle build file and hence don't want to use the existing 'sonarqube' task.
I think that you are referring to the following improvement that we want to do on the Jenkins SonarQube plugin: SONARJNKNS-217
This should come sooner or later. In the meantime, you're right, there's no easier way than what you described - unfortunately.
I am using Maven as a build tool and Jenkins as a CI tool. Currently I have a Jenkins job configured with a Maven build step.
I started using SonarQube and was wondering what is the advantage of using the Jenkins SonarQube plugin and configuring the SonarQube analysis as a post-build-action over simply adding sonar:sonar to the goals of my existing Maven build step.
Thanks and best regards,
Ronald
You can save a lot of configuration. So, if you use jenkins sonar plugin you can centralize database credentials and sonar credentials but if you make a decision about execute sonar:sonar in each jenkins job you will configure each with the same credentials.
I just found: Why use sonar plugin for Jenkins rather than simply use maven goal "sonar:sonar"?
And to add one reason: Using the Jenkins SonarQube plugins one can specify "Skip if triggered by SCM Changes". This is nice if you trigger your Jenkins job for each commit but only want to do a SonarQube analysis at a scheduled time, e.g. one per night.
And here is a summary of the the points made by "emelendez":
Centralize database credentials and sonar credentials Use jenkins
Use jenkins sonar plugin configuring SonarRunner for non Java projects
I've just changed to maven-sonar-plugin from the Jenkins SonarQube plugin to avoid divergence of information between the pom.xml and sonar-project.properties.
For example, developers elsewhere had bumped the project version number in the pom.xml, but they don't use the Jenkins builds and didn't care about the sonar-project.properties (or probably understand it). By switching to the maven plugin instead, the project version is defined once and referenced in the sonar property set within the pom.
The downside is that I no longer have the SonarQube link from the project's Jenkins page.
I'm not sure where the responsibility might be for adding this link back for projects using maven-sonar-plugin... The link is "owned" by the Jenkins SonarQube Plugin, but this is not being used here. Meanwhile the maven-sonar-plugin component is integrating with maven not Jenkins.
Something would need to observe the build and extract the SonarQube link which is emitted as a [INFO] ANALYSIS SUCCESSFUL, you can browse http://... line in the log.