I am new to Jenkins. I am running my jobs using Jenkins declarative pipeline. My jobs has both snapshot version and release version. I want to push only release version to nexus (the reason is just to make sure it is not very much crowded in nexus). Can i control this in my pipeline script something like running multiple steps like, if my pom version has SNAPSHOT version, don't run nexus stage and if my pom has release version run nexus stage. is it possible to control this scenario in Jenkins pipeline. please assist
Depending on how you know is a SNAPSHOT or a RELEASE version. For example if you use git branches (develop = SNAPSHOT , master = RELEASE) you can use GIT_BRANCH variable in order to select if you must deploy push to nexus
If you must read it directly from pom.xml, read this:
Extract version ID from POM in a Jenkins pipeline
There you get the version and select if is a SNAPSHOT or RELEASE and the upload the file acoordingly.
Hope it helps
Related
I am building a new Jenkins job to install the package once a new build is ready.
If I set the Jenkins job run at every hour, how to avoid install the same build?
Example:
Build 1.139.506 just ready
Then Jenkins kins job trigger installation for build 1.139.506
At next hour, Jenkins job is triggered again.
If build is still 1.139.506, then stop job, no installation needed.
Else, repeat step to install new build.
There are different ways to achieve what you need.
Use an SCM repository and do polls on the repo. So Jenkins will only run the Job if the source code changes.
Use an SCM and tag the source when you release a new version, in this case, you can run the Job if a new tag is created in the SCM.
Save the last deployed version somewhere and check if the current version is different from the last deployed version.
Check the deployment environment for the deployed version and check if the current version is different, if so run the Job, else skip.
Is there a way to list all the version uploaded in Nexus repositories.
I am working with Jenkins, and trying to show the versions uploaded in Nexus repositories.
EDIT:
I am not using MAVEN releases, i have the compresses files as zip.
The format we have is ,
ABCD releases
com.abc.abcd
appname
v1.0.0
app_v1.0.0.zip
How do i use Repository connector /Artifact resolver to configure to list all the releases under ABCD releases.
yes with jenkins nexus plugin you can make a parametrized job to display a specific version before the job start.
more detail look at this page
https://wiki.jenkins-ci.org/display/JENKINS/Repository+Connector+Plugin
I am using the Jenkins Artifactory plugin to publish build artifacts.
I renamed my job on Jenkins but I still see the old name of the job under Artifactory "Builds".
I am new to Artifactory (used Nexus in the past) and I am not sure if there's anything I need to do on Artifactory side to make the necessary name change.
Thanks,
Bella
Artifactory does not discard old builds unless you specifically instruct to do so by deleting those builds so what you're seeing is just the builds from the 'old' job.
Now that you have renamed the job new builds (with the new name) will start showing in the Builds pane once you've started the job.
If you'd like to discard the old builds (from the old jenkins job) you can simply do it from the Builds pane or with the REST api
In Jenkins, I have a "Build" job setup to poll my git repo and automatically build on change. Then, I have separate "Deploy to DEV", "Deploy to QA", etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.
However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it's possible the artifact could be incompatible between versions. So, it's ideal that I ensure that the build and deploy jobs are run using the same git checkout.
Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don't see any options or plugins that do this.
Any ideas on how to simplify this configuration?
You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.
The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like "LatestSuccessfulBuild") at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.
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.