We are using the ant build tool in our project. We have build.xml and stored the properties in build/version.properties. I am facing issues in task setting up a minor version from build.properties to GitLab-ci.yml. I want this minor version to increment after every commit. I am attaching some images for reference of build.xmlscript for updating the minor version.
In gitlab-ci.yml we define a
variable: MANEN_CLI_OPTS:" -s settings.xml --batch-mode -Dcc5_majorversion=5.143 -Dcc5_minor_version=$CI_PIPELINE_IID"
Related
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.
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.
We have something very strange on jenkins.
If we commit some codes, Jenkins will notice that the changes are there and the build will be triggered. But it builds with OLDER CODES, not the new ones!
How could it happen? Did we configure something wrong?
As source control we use git. Jenkins knows the repository and if there is something changed in the repository, jenkins starts to build.
Our build configuration is like this:
Build:
Maven: 3.04
Stamm-Pom: pom.xml
Goals and Options: -e -s ./settings.xml -Pdev clean wildfly:deploy
And we don't have any pre-build steps.
Problem solved. We commited caches into the source control repository. And we only use wildfly:deploy to build, then the caches are used. We just need to delete the caches and add lines in ".gitignore" to ignore the caches, so that the caches are not commited any more.
I'm trying to get a reference to my Xcode projects CFBundleVersionString or CFBundleVersion within my Jenkins Build.
My goal is to be able to set the build numbers in this sort of fashion ${CFBundleVersionString}.${build_number}. This way the Version is dictated by the project and the build number is added on when the project is built.
Is this possible at all? I know that you can reference ${build_number}. Also I know that I could include a parameter in the build that is dictated, but I would prefer it all be managed through the Xcode project since our builds are triggered by github commits.
You can read CFBundleVersionString from your Info.plist file with:
export VERSION=`defaults read ${INFO_PLIST} CFBundleVersionString`
output this to a property file:
echo VERSION=$VERSION > version.properties
and use this file to inject environment variables to your jenkins build.
You can then use this variable with Build Name Setter plugin or simply us it in build mails.
Similarly you can update the version inside the plist with:
defaults write ${INFO_PLIST} CFBundleVersionString ${VERSION}.${BUILD_NUMBER}
If you are using the Xcode Plugin, you have CFBundleVersion available as $VERSION and CFBundleShortVersionString as $SHORT_VERSION.
I found $SHORT_VERSION by searching the XCode Plugin source code.
I have been looking everywhere for something that works from Jenkins.
shortversionnumber=/usr/libexec/PlistBuddy -c "print CFBundleShortVersionString" ${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH}
But if your build has not happened yet, you will need to manually specify the location of the plist file.
That is all!
I am new to ant and Ivy. We are using Jenkins for CI with ant for builds, Ivy for dependency manger. We have several modules/projects which generate jars and wars, which can be independently versioned and released (not all modules will be released at the same time), so, need to maintain version number separately for each module. We want to use the version format A.B.C.D (ex: 1.2.1.2). I found I can use a property file to enter a version number and use ant BuildNumber task to increment the number for our nightly builds. So, once all the features are in and tested we move the last successful nightly build as new released version but we want to change the version number without rebuilding it. For example last successful build was 1.2.1.20 and it was tested thoroughly and has all the feature, we have to make this build from 1.2.1.20 to 1.3.0.0 without rebuilding the modules. How can I do that using ant? And also I need to publish them to my shared repository with the version 1.3.0.0. How do I do that?
Also, we want to create a zip file for each module with all dependency files along with the module's jar file for delivery. Is there any ivy or ant tasks that can help to create this?
I think you've asked two questions...
Generally, every build I create is releasable so I'm always incrementing the last digit in my release number scheme. For controlling the version number I prefer to use the ivy buildnumber task, which increments based on what has been previously pushed to your repository (very useful).
Creating a zip package is quite straight forward. Just alter your ivy file to publish more than one artifact.