Currently I try to configure Jenkins, so I can do my release builds automatically. It should change the version number from SNAPSHOT to a release version, and do all the SVN commit stuff. After this is done, it should switch it back to a new SNAPSHOT version and commit it, too. Before I switched from maven to gradle, the same plugin worked correctly.
I already created a gradle build, that works correctly. It is reading the version from the property "version" in the gradle.properties file. This version is the one that is used in the gradle build. It's also possible to run "artifactoryPublish" to publish the JAR to my artifactory.
The problem:
When I open the dialog "Artifactory Pro Release Staging" (http://imgur.com/T44BtQB) it is not filling the fields "Release version", "Next development version", and none of the other fields. If I fill the fields by hand, everything is working correctly. As well the version in gradle.properties is changed and checked in correctly.
How could I solve this problem?
Used Versions:
Jenkins Version 2.7.1
JFrog Artifactory 4.7.4 rev 40169 (free version)
Jenkins Artifactory Plugin 2.6.0 (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Artifactory+Plugin+-+Release+Management)
Gradle 2.14.1
Thanks!
According to your description, when you access the "Artifactory Release Staging" page, the "Release version" and "Next development version" fields are empty. This might be because you did not define the property names for your version and next development version in your Jenkins job configuration.
Here's how you do it:
1. Open your gradle.properties file and find the name of your version property. For example, if your gradle.properties contains:
version=1.2-SNAPSHOT
then the name is "version".
2. Open your Jenkins job configuration, and put "version" in the "Release property" and "Next development properly" text fields. You should find them under the "Release Staging" configuration.
Now, the Artifactory Release Staging page should know where to take your versions from. This configuration is not required when using Artifactory Release Staging for Maven, because in Maven the version can be found at one place only - in the pom file.
Hope this helps
The way I see it, it seems your gradle.properties could not be committed with the rest of your files with SVN. Can you check this?
If it is committed and is effectively present with all the other source files when Jenkins executes the build job, it may be worth ensuring that the Jenkins build job is looking for the gradle.properties file at the right place. The Gradle plugin's default behaviour is to search for the gradle.properties file at the root of each project. If that's not where your gradle.properties file is, you may want to set the path manually. To do so, add the following under 'switches', in your Jenkins job:
-Dgradle.user.home=$HOME/.gradle
Let me know if this helps.
possibly this happens due to the below reason, while reading the properties
File permission - check the file group and owner in the work-space where your gradle.properties is located
2.(Not sure on details, it helped me in resolving) After updating the correct file owner group, removed the version property from jenkins artifactory release management section and triggered the build and once it is successful and included the version in jenkins artifactory release management section and triggered the build and it solved the problem.
Related
I have this log4j-1.2.12.jar file in my jenkins server
Path to it: /data/jenkins/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar I got this Apache Log4j Unsupported Version Detection message from security team, how to resolve this I tried downloading the latest version but it is something like this log4j-api-2.19.0.jar
No, it's not "in Jenkins", more accurately, log4j is not a part of Jenkins. Jenkins consumes its jars from the exploded war in ${JENKINS_HOME}/war/WEB-INF/lib. It is not located there.
If a plugin consumes log4j, that would be found within the exploded plugin directory at ${JENKINS_HOME}/plugins/<plugin_name>/WEB-INF/lib. The status of log4j as it related to most plugins was tracked under JENKINS-67353.
What you are referencing is the maven local repository, .m2/repository. This structure is created when running a maven build on the controller; the dependency jars specified in (one of) your build's pom.xml.
The guidance in the comments is correct; find the appropriate pom.xml and update it, then rebuild.
You can verify these claims by deleting the entire .m2 directory (or moving / zip;delete if you are paranoid) and restarting Jenkins. You'll discover Jenkins is running fine and the directory remains empty. Run your maven jobs and it will repopulate, including log4j-1.2.12.jar, assuming it's still specified in your pom.xml. Fix your maven pom.xml, delete the directory, rerun your jobs and it should not reappear.
Perhaps you have already updated your pom.xml but never cleared out your local maven repository, then it will not repopulate (you could check the timestamp of the directory to know when it was first/last downloaded).
You can also delete referenced portions of the repository by specifying mvn dependency:purge-local-repository and adding -DreResolve=false to avoid re-resolving. Of course, if you've already updated the pom.xml, it would remain since it's not referenced in the pom.xml` (yes, it would be nice if there was an option to purge all or most of a repository or all version of a given jar, but ...).
We have a master and two slaves.
On Master there is a job which checks if there is new version on Nexus and if yes downloads latest jar and updates latest version (i.e. xxx-0.012.jar) in text file VERSION.TXT. (It is possible to access nexus only from master).
We need to run downloaded jar on slaves so we need to copy it from master.
We have a job which triggers few other jobs:
1)CHECK_LATEST_JAR: job which runs on master and checks if there is new version of jar on nexus, downloads it.
2)GET_JAR_TO_SLAVE: job which runs on slaves and should copy latest jar from master
3)RUN_JAR: job which gets latest jar name from file VERSION.TXT and runs jar with such name.
In CHECK_LATEST_JAR if newer version is found on nexus we download it to workspace and archive artifacts (jar + text file with latest version).
Now in GET_JAR_TO_SLAVE we wanted to use "Copy artifacts from another job" plugin - but here we need to add a condition to run this step only if there is newer version as if there are no artifacts in CHECK_LATEST_JAR this job fails..
Is there a way to compare file which is located on master with file which is located on slave?
Tried to use conditional step with groovy script - but cannot figure out how to tell it to access file on master if job runs on slave.
Just came across FSTrigger plugin which probably can be used - but same problem here how to tell it to monitor file VERSION.TXT on master and if there is a change to run job on slave.
would be grateful for any ideas how we can achieve our goal.
thanks
We found plugin Copy Data to Workspace and used it to copy file containing latest version from folder on Master to workspace of job running on one of slaves.
After that we compare content of files using Conditional BuildStep plugin strings comparison with Token macro and if files content is different we copy artifacts of the job where jar is downloaded.
I have Jenkins Version 2.89.4 with the actual MavenReleasePlugin and SVN as repository. The SVN - Credentials set in the project configuration will not be used from the MavenReleasePlugin as I am aware.
Do I press in Jenkins the Build Release Button, I may enter user and password for SVN. This works fine, but it is work interactive.
How and where can I store these credentials in the background in Jenkins or any settings.xml ? so that I don't have to enter the credentials each time I am building a release.
You tell maven NOT to work in interactive mode using
mvn -B release:prepare
or
mvn --batch-mode release:prepare
Using batch mode with no other configuration will cause the Release Plugin to use default values for the release version, the SCM tag, and the next development version. These values can also be set from the command line. So you can set in the command line the "-username" and "-password" arguments.
Another option is to create a properties file that contains the version information for the project you would like to release. In this property file you can place the username and password.
Read more here and here.
Hope that helps!
I'm very new with Jenkins. I have tried to run projects on Jenkins but all are fail. I don't know whether the configuration is wrong or something. I have read the instruction on the jenkins-ci.org but I didn't understand anything. Anyone can give me a demo with Java project? By the way, show me the Jenkins configuration. Thanks all!
First question, do you want to build a Maven project?
If the answer is yes, you can create a new job with this template "Build a maven project".
You just have to configure your SCM tool (Git, SVN, ...) and when you want to pool your code (cron tab).
Next, in the build section, you have to declare your Maven goals (clean install for example) and the pom.xml file location (if the pom.xml file is not in the root folder).
That's all.
How to configure ISSUE link for allure jenkins plugin?
There are only "Default Results Directories" and "Default Report Version" settings in global jenkins settings.
Allure report is generated normally after test, but Issue links are broken.
That configuration has already been implemented (https://github.com/allure-framework/allure-jenkins-plugin/pull/39), but still not merged :( .
So, IMO you have only few options. Either build snapshot artifact with that patch applied or launch Jenkins with JVM arg -Dallure.issues.tracker.pattern=http://your-bug-tracker.com/%s (but you will have to ensure it exists for slave machines as well).