I've set up 2 free style jobs, build-app and deploy-app. build-app poll the scm and builds the app, which is Maven based, and install the artifact in a web server (internal repository server), then it calls deploy-app. I would like to pass the version of the pom file () to the downstream job so it can download the correct artifact and install it on the machine. I found some answers suggesting put the version string in a properties file and use InjectEnv plugin, but I prefer read it from the pom itself. Any ideas?
Thanks!
When you build inside Maven, you have access to the pom file version as ${program.version} and can do anything you wish with it.
The downstream freestyle job can also run Maven using the same pom but a different target. The version should be the same if you take care to keep it from changing in the interim. (This suggests a procedure that should always be followed.)
So, for example, that Maven target can run a Groovy script or an Ant script that will pick up the correct file from the repo and deploy it.
Related
I have a project in which I am using maven-release-plugin to make periodic releases. I also have some script files like start.sh and stop.sh which helps in starting up the project with multiple steps using just one command. The script contains commands like, (but not limited to)
java -jar module-0.0.1-SNAPSHOT.jar
My problem is, when I run release plugin it updates all the POM files but does nothing to this script file. I want to update these script files as well along with POM files. These script files contain the version number exactly the same as pom file and the way I mentioned.
Currently, I am updating these files manually after each release.
Any help will be greatly appreciated.
Maven release plugin is indeed all about releasing the maven version. Maven as a build tool, builds the artifact and releases it.
It has nothing to do with various script files. So you should decide first of all:
Whether its a maven responsibility at all to deal with these scripts.
If so, you can create your own plugin that will do the changes. Or alternatively you can use filtering feature, Maven build helper plugin to get the access to the versioning information and assembly plugin to prepare the distribution.
Otherwise, I see 2 possible options:
Alternative 1
Rename the versioned artifact with something generic that doesn't really include any maven related versioning information.
In this case the script will always be the same and will run: java -jar my-module.jar
Alternative 2
Complicate the script so that it will find the file and resolve the version dynamically. Then it will memorize the path to the file in some variable and will run java -jar $here_is_the_resolved_file_with_version.jar
Are there any plugins or ways to download the dependencies for a maven project from Jenkins? I am using Jenkins for a multi-module desktop application. Although I know I could just archive all dependencies, I don't see why there isn't the ability to download dependencies using maven which installed on the same machine as Jenkins. Preferably one would specify the location of a pom and then have the ability with one click to download all the dependencies for that pom. Can you do this? I do not need or want an entire binary repository for this feature.
Edit: I will try and rephrase this as I don't think people are understanding.
In Jenkins one has the ability to archive artifacts at the end of a build. Also in jenkins you have integration with maven. When building a jar in maven you have arguablly 2 options:
You can either use the assembly plugin which zips all .class files
together with those produced from your source code resulting in 1 jar
You can create a jar just source code which references all
dependency jars which are located in a separate folder.
In Jenkins one also has the ability to download the latest artifact. Now if I am using Option 2, I can either archieve just the jar which my sources produced, which I would say is more desirable for space and is the whole purpose of the archive functionality, or you can also archive the libraries too.
Here is the PROBLEM!! If I don't archive the libraries then I cannot easily run this jar, as it is a desktop application and its dependencies cannot be obtained in the same mannor as clicking on a link from jenkins. So lets say my question is what is the easiest way to obtain them? Extra info: assume jenkins is running as a server and you can't use artifactory or another server application, that seems to me to be massive over kill.
Use the maven plugin and create a maven job for your project. Jenkins will then use the maven command you provide in the job configuration to build the project. This means maven will download the projects dependencies and store them on the machine jenkins is running. Normally this would be <JENKINS_HOME>/.m2/repository. This way you get a local repository that only contains the dependencies of the projects you created maven jobs for.
We are using Jenkins to build (maven) & deploy artifacts (JARs & *WAR*s) to an in-house artifactory server (both snapshots and releases).
For deployment, currently, we got Jenkins jobs that package the war file (from a release scm tag) and deploy to different environments/servers. We want to skip the package phase as it seems unnecessary to package it again & again for a released version because it's not possible to get a different copy of war file even after trying 1000 times.
We are looking for a way in Jenkins to get the artifact (war) from Artifactory and deploy it to a container. I am sure other people would have faced this situation too but I am not able to find any online material regarding this.
Is there any Jenkins plugin that takes a war file from Artifactory (based on a version) and deploy it to a remote container?
If this is not the right way of doing it then what are the recommendations for any other approach?
Thanks
I don't know about a plugin which takes a version # and deploys that, but you can build a Jenkins job to deploy the last successful release to a previous environment (thus copying from DEV-->QA for example.)
To do this, you would use the copy-artifact-plugin.
Here's an easy to follow run-through of this kind of setup:
http://www.lordofthejars.com/2012/09/deploying-jee-artifacts-with-jenkins.html
Every artifact stored in Artifactory will have a unique URL that includes the version number. It will take the format
http://artifactory-server/repository-name/path-to-artifact/version/filename
e.g.
http://artifactory/apps-releases-local/com/yourorg/yourapp/1.5.67/webapp.war
(depending on how you do your packaging, the WAR file name may include the version number as well).
So your deployment job can construct the Artifactory URL and download the file. Depending on how you have security set up in Artifactory, you may need to authenticate the request.
I am tying to set up a Jenkins Pipeline.
The first stage is done, the code compiles, is tested, inspected and deployed to Nexus.
I would like now to make a second stage on the pipeline where the war is checked out from Nexus and deployed on tomcat.
Actually I already integrated the maven-tomcat plugin to deploy on Tomcat.
My question is how can I check out the latest build of the war ?
Is there any maven or jenkins plugin for that ?
Many thanks,
Patrick
Your binary repository manager (Nexus) should ideally occupy the following position in you overall architecture:
You can use Jenkins as your provisioning tool, but ideally it should launch some sort of process which pulls the artifact to be deployed directly from Nexus (If nothing else it's more efficient).
This is a lot easier than it sounds. For example the Nexus REST API could be called from a shell script to download any desired revision of an artifact. For example:
$CATALINA_HOME/bin/shutdown.sh
curl -o $CATALINA_HOME/webapps/myfile.war http://myrepo.com/service/local/artifact/maven/redirect?r=releases&g=com.myorg&a=myfile&v=1.1.1&e=war
$CATALINA_HOME/bin/startup.sh
Finally, perhaps you might wish to consider a dedicated system for managing your deployments? An interesting solution I've been playing with is rundeck, which has a plugin for Jenkins. I really like rundeck, due to it's simplicity a trait it shares with Jenkins. There is also a plugin for Nexus that enables rundeck to provide a pull down list of artfacts eligible for deployment.
See download-artifact-from-nexus.sh script at https://github.com/cescoffier/puppet-nexus/tree/master/files
In my case, I modified it to use wget instead of curl. For some reason, curl wouldn't work for me.
I suggest you create a new pom for this. That way you are not bound to jenkins.
You need not explicitly checkout the artifact from nexus (note that this is called downloading from the repository in maven speech). You can specify a different war file location in the tomcat maven plugin. See the documentation. For downloading the latest version from the repository see the answers to this question.
i get the same problem with curl, i solved it buy adding the parameter -L, so that curl will follow the redirection to download the artifact, wget follows the redirection by default.
Below syntax has worked for me.
wget --user=admin --password=admin http://192.168.0.3:8081/repository/simpleapp-snapshot/in/javahome/simple-app/3.0.0-SNAPSHOT/simple-app-3.0.0-20210513.143540-1.war
I've got a Maven project that Jenkins builds and deploys to a remote repository. I then need to copy the deployed .war to an external location. I've been trying to do this with a post-build shell script but I don't see any way to get the build information from maven (for example, the URL of the deployed artifact). Is there a way to get it, or a way to do this that's more integrated into maven? I can calculate the deployment path using Jenkins build parameters but it seems like a hack.
Thanks,
Steve
After a maven build you should always find the build artifact at
target/<artifactId>-<version>.<packaging>
You can access this path within the maven pom.xml by using the maven properties (see pom reference)
${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
To copy the artifact to another location after the build you can use several approaches described e.g. in this thread.