I've created two Jobs in Jenkins, JobB is dependent on JobA.
While configuring JobA, I am doing post build action to deploy artifact in Jfrog and it is successfully deployed.
But while configuring JobB, I am configuring prebuild setup with to find artifacts and providing the detail, when I am running Job I've checked that JobA jar is downloading but then also I am facing compile time issue, I've written repository tag in dependent pom.xml.
But then also I am facing compile time issue.
Related
I installed the Deploy Plugin on my Jenkins in order to automate the deployment of my Maven built war packages to Tomcat 7. The problem is that I am able to use the plugin to deploy to a remote Tomcat server only if they are made within the same job that uses the deploy plugin. In other words, I have not been able to set up a standalone job that deploys artifacts made by a different job.
For example, I have a job named pack.foo. It uses the source code in /var/lib/project/module to create module.war and put it in /var/lib/project/module/target. However, because of the Maven version setup, the artifact posted on pack.foo's artifact page is something like module-2.0.0-SNAPSHOT.war.
The only way I am able to deploy module.war is if I add a Post-build Action to pack.foo and specify **/module.war to be a remote Tomcat manager URL (provided I have the manager's credentials in Jenkins config). Then the job's console output logs that /var/lib/project/module/target/module.war was deployed to that URL:
Deploying /var/lib/project/module/target/module.war to container Tomcat 7.x Remote with context
[/var/lib/project/module/target/module.war] is not deployed. Doing a fresh deployment.
Deploying [/var/lib/project/module/target/module.war]
How can I use this, or another plugin, to deploy a WAR artifact that was made in a separate Jenkins job? I would like to have separate jobs for artifact creation and deployment. The plugin wasn't finding **/module-2.0.0-SNAPSHOT.war or even **/module.war built by another job even though there was definitely a file on disk that matched that pattern.
See the paragraph on the Deploy Plugin's page you linked:
How to rollback or redeploy a previous build
There may be several ways to accomplish this, but here is one suggested method:
Install the Copy Artifact Plugin
Create a new job that you will trigger manually only when needed
Configure this job with a build parameter of type "Build selector for Copy Artifact", and a copy artifact build step using "Specified by build parameter" to select the build.
Add a post-build action to deploy the artifact that was copied from the other job
Now when you trigger this job you can enter the build number (or use any other available selector) to select which build to redeploy. Thanks to Helge Taubert for this idea.
I've built two jobs in my jenkins instance:
Gradle job builds war task and generates a war file ready to be deployed.
Docker job builds a Docker image from a repository.
Both are working fine. However, the second one depends on the first one. So, Docker job needs to use the last war file generated by Gradle job.
How could I be able to do that?
You can use parameterized job trigger plugin to trigger sub jobs with parameter. You have to do the following to resolve above problem:
Create parent job which will have two sub jobs which you mentioned.
Then trigger first job and archive the artifacts which is war file.
Then pass last trigger build number of first job to second job and start that job. Use Copy artifacts plugin to copy war from first job with specific build number which was passed before starting.
This will resolve your problem!!!
Use a post build task for your first job (Gradle job), just cp the war file into the workspace of Docker job. Then configure Docker job so that it does NOT clean workspace before build. And for the post build action, choose delete workspace after build. This will ensure you will only have the latest war file in Gradle job workspace. Also, you should use post build trigger, if your not using that already.
Good Luck!
I have a maven job in jenkins. Normally at the end of the build the artifacts will be deployed to artifactory via jenkins post build action.
But if I make a release build I get an error from jenkins in this case.
So, is there a possiblity to avoid deploying the artifacts at the end of a release build.
Let me precise the error. The maven goals are 'clean install'. I need the post action for deploying to artifactory by a 'normal' job. If I make a release of this artifact via the M2 Release Plugin the deploying of the relased artifacts will be done by the M2 Release Plugin itself. But at the end of the job the post action tries to deploy artifact with the old SNAPSHOT version which is not allowed by artifactory.
Jenkins M2 release plugin (used maven-release-plugin of Maven). If you have created a Maven job (instead of a Free Style), then in M2 Release section in job's configuration, you'll see the goals are:
-Dresume=false release:prepare release:perform
If you replace it with the following M2 release plugin won't call deploy goal which is initiated by release:perform goal by default.
-Dresume=false release:prepare release:perform -Darguments="-Dmaven.deploy.skip=true"
In my case, I didn't want the artifacts to go to Artifactory as soon as release:perform and release:prepare goals were completed, so the above helped. But, even though Jenkins job has a Post Build action as "Deploy to Artifactory" to either snapshot or release repositories (depending upon what kind of build you have aka automated/manually run build job OR by running Perform Maven Release ), it never called the post build action.
This can be good in the sense, now I can call deployment using the generated release artifacts in an environment and if the deployment/some IT tests are successful, then I can upload the artifacts to Artifactory. Downside is, what if your deployment depends upon fetching the new artifact from Artifactory/Nexus (i.e. somewhere in deploy script's logic) then you can't have that working until you copy artifacts from one job to another child job.
Apart from that, maven deploy goal requires valid / settings in either settings.xml or pom.xml where the you specify for each of the above sections, which are defined under section, must match with the value of section defined in setting.xml/pom.xml.
One can defined / set the value of section to use a non-release repository which is higher in order (for artifact resolution) than a snapshot repository i.e. use libs-alpha-local or libs-stage-local and then let maven deploy goal deploy the artifacts to Artifactory/Nexus.
Later, upon successful deployments to higher environments (like QA/PRE etc), you can move the artifact from alpha/stage to libs-release-local.
IS_M2RELEASEBUILD Boolean variable which comes with M2 Release plugin can be used in a conditional step to deploy here or there or not at all.
In the configuration of the 'Maven release build' you can set in the advanced mode a 'Release environment variable' (default is IS_M2RELEASEBUILD). Later in the post-bild-action 'publish artifacts' you can check if this environment variable is set and then the deploying is skipped.
I'm thinking you may want to create a separate jenkins job just for your release builds. And under post build action to run different set of maven commands just to package the artificat and not install it to the artifactory. That being said if other applications depends on that artifact you do not want to release. This may be causing versioning problems.
You should take a look at Artifactory Jenkins plugin. 1. It deploys with errors. 2. It has built in release functionality. 3. It will provide you with unique buildInfo functionality for saving build information tougher with artifacts in Artifactory, https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
If I can assume you're using the M2 Release Plugin, then there's another issue.
Skipping the deployment after a release would be an unnecessary workaround, since I've seen this work. You should try to fix this by the root cause.
It would help if you could provide more info about the error.
For posterity:
One of my Jenkins jobs disappeared after I upgraded some plugins.
I looked through the error log, and found that the Promoted Builds Plugin was failing while parsing the job config.
What went wrong?
It appears that the Promoted Builds Plugin release 2.9 broke in my scenario, which specified a promotion action to build a parameterized job. I removed the section of the job conf file pertaining to promoted builds, restarted Jenkins, and the job reappeared. Then I reconfigured the promotion action, and all seems fine.
So I got few separated jobs in Jenkins. The first one gets the project from a Git repository, builds it and produces artifacts. And another one has to copy certificates from the first job and publish them to Artifactory (tried to make it using the Artifactory plugin). But the thing is that the Artifactory plugin's available only in the Build job, there's nothing like "Generic-Artifactory integration" in second job's configuration.
Does anyone know what are the requirements for making the plugin work in the Publish job?
You can write a small shell script leveraging Artifactory REST API and execute it in your second, non-build job.
I have done a similar thing with maven and a zip file. I have deployed a zip with a build step in maven calling a deploy:deploy-file and setting my Artifactory repository in settings.xml and deploying directly on my artifactory repository.