I want to compile my ant based projects committed in perforce using Jenkins. Just to achieve this i have created setup jenkins along with required p4 and Ant plugin but i am facing issue while giving path perforce depot as jenkins giving error
I followed these instructions
but it didnt work
Jenkins error screenshot 2
Basically i cant configure my module committed in perforce and build it using jenkins.
Related
Background:
So my team is using Microsoft's git services and we've set up some CI tests. We are not using Maven, and the project is connected to the remote server through the Eclipse Microsoft Team services plugin, but I try to interact with the remote repo mostly through the command line.
Current Strategy:
I'm not too familiar with how to deal with dependencies on a remote repo for Java projects but I've tried simply pushing the .jar dependencies in our build path with the rest of the source code (I know they're big and there's probably a better way to do this).
Problem:
When I push the .jar files, the CI tests still fail with the following errors:
src\JBLASTests.java(1):src\JBLASTests.java(1,): error : [javac] d:\a\1\s\
src\JBLASTests.java:1: error: package org.junit does not exist
src\JBLASTests.java(5):src\JBLASTests.java(5,): error : [javac] d:\a\1\s\
src\JBLASTests.java:5: error: package org.jblas does not exist
And then more error reports related to the missing symbols due to the packages not being found.
Questions:
1) What else needs to be on the repo to make the build work?
2) Is there a better way, besides Maven, to link the libraries to the repo?
(I'm not averse to using Maven I just want to find a simpler solution for the interim).
Apologies if this is a duplicate. I searched but couldn't find any other posts regarding this situation.
It looks like the dev who set up the CI tests set them up with an Ant build task despite that not being how we currently handle dependencies. Thank you howgler for pointing out that the CI might be building differently than I do locally. I'll post this answer in case anyone else runs into this issue and doesn't think to check the CI build settings (and also update the title appropriately).
Lesson
Make sure that the CI build task is the same as how you're building locally. Until you add dependencies and try to push them, your builds might be succeeding, so it can be misleading that your CI settings are incorrect.
This is related to my last question
One of the answers suggested that the error wasn't related to the AWS plugin but rather Maven. I used this as a reference to install the Maven plugin. The installation finished fine.
I made a simple Java project called Maven with a single class that outputs "Hello Maven". I then tried to configure the java project into a Maven project by going to configure -> convert to Maven Project. These are my settings for configuring my simple project into a Maven project(all default)
After clicking finish, I get into an endless loop. I've tried restarting Eclipse but that didn't work. This tells me that the issue in my other question was related to Maven. I'am new to Maven. Can someone guide me into the next step for debugging this issue? There's no error output I can look at.
I'm using the JaCoCo Maven plugin and agent to measure and retrieve the code coverage data of an application which is tested nightly.
This is the schema of the architecture:
My Maven project is configured with the JMeter Maven plugin to execute some API tests during the Maven verify phase.
The Maven command executed by the Jenkins server is the following
mvn verify org.jacoco:jacoco-maven-plugin:0.7.8:dump sonar:sonar -Djacoco.address=TEST_SERVER -Djacoco.destFile=/proj/coverage-reports/jacoco-it.exec -Dsonar.projectKey=sonar_test -Dsonar.projectName=sonar_test -Dsonar.branch=sonar_test -Dsonar.jacoco.itReportPath=/proj/coverage-reports/jacoco-it.exec -Dsonar.java.coveragePlugin=jacoco -Dsonar.language=java
As you can see first the tests are executed through the verify phase, then the jacoco:dump goal retrieves the coverage data from the test server (I configured the server to run the JaCoCo agent) and at last the data is uploaded to my Sonar server.
The "strange" behaviour I'm having is that if I run this command on my computer and then on Jenkins (configuring the Jenkins project accordingly) in the SonarQube page I get different coverage results. Moreover, if I configure the Jenkins project and then I simply COPY it creating a new (but equivalent) Jenkins project, the results are different.
I tried different configurations and cases, but I cannot understand what the problem can be. Am I not considering some JaCoCo constraints (e.g. someting related to the Jenkins project name)?
As said in the question comments, the artifact deployed on the test server and the one compiled during the verify phase on which the report is generated must be exactly the same, so it is not enough that the code is the same.
To solve my problem I had to implement this workflow with Jenkins:
Do a mvn package on the project
Deploy the generated WAR on the remote server using Ansible (we already use Ansible for nightly deploys and other tasks on remote machines)
Run the remote tests without recompiling the wars. To do this I had to add the Maven flag -Dmaven.compiler.useIncrementalCompilation=false (thanks to this and this for the hints) in order to not re-compile the artifacts during the verify phase
Retrieve (dump) the JaCoCo coverage data
So the Maven command described in the question has been split in two commands: the one which creates the package and the one which performs the tests and retrieves the JaCoCo data without recompiling the artifacts.
Ok, first up I am almost completely unfamiliar with Java and Java tooling.
I am attempting to contribute a bugfix to a Jenkins plugin. Code-wise the fix is simple, my problem is in trying to compile the project and run the tests locally.
I have installed IntelliJ IDEA 15CE and started a new project, pointing it to my local clone of the plugin repo.
It has gone away and 'downloaded the internet' in terms of Maven dependencies. Mostly everything looks ok. What I want to do is to run the tests...
If I right-click at the root of the project and select 'Run All Tests' I get the error:
Error:(115, 29) java: cannot find symbol
symbol: variable Messages
location: class hudson.plugins.copyartifact.BuildSelector
The source of this error is a line:
console.println(Messages.CopyArtifact_MissingSrcArtifacts(srcDir));
https://github.com/jenkinsci/copyartifact-plugin/blob/master/src/main/java/hudson/plugins/copyartifact/BuildSelector.java#L115
As far as I can tell the Messages symbol should resolve to this properties file:
https://github.com/jenkinsci/copyartifact-plugin/blob/master/src/main/resources/hudson/plugins/copyartifact/Messages.properties
...which IDEA recognises as a 'Resource Bundle' in the project tree view.
But it doesn't seem to recognise it when compiling the project.
I have no idea where to start fixing this. The tests run fine if I push a commit to a pull request on GitHub and let the cloudbees.com Jenkins server run them, but I'd like to be able to test stuff locally first.
Run the maven compile command from Intelli-J Maven tool. After compiling error will vanish.
When you compile it will generate a Messages.java file in generated sources automatically.
I am using Jenkins to set-up a DevOps pipeline for a Java project. And am stuck at one scenario of deployment. If somehow there has to be roll-back of build on Tomcat server and build that has to replace this one has to be last stable build.
Suppose build#20 is deployed on server which is stable and build#21 is deployed in next build cycle but after deployment its found that this new build has issues. Now i want to replace this build by the previous build that is build#20.
The plugin I am using on Jenkins doesn't provide the facility of roll-back. Please help me out.
Plugin for deployment : https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin
Just re-build build#20, call it build#22, and deploy it.
"Deploy" your build results to a deploy-candidate location and only (really) deploy them to Tomcat from there after it has turned out that your complete build process is stable.