I have two Jenkins jobs that build our software.
One job runs when it detects a change in the repository. The other job runs nightly.
I want the nightly job to start from a clean slate, that is, build all the artifacts - jars, wars, poms, rpms, etc. On the other hand, I want the other jobs to use existing artifacts - I already do this.
For the nightly job, I delete the local .m2 repository. But how do I delete the appropriate version in artifactory? For example, if I'm building a 1.0.0-SNAPSHOT version, I want to delete ALL artifacts in artifactory with that version beforehand.
If you just want to delete old snapshots, you can set Max Unique Snapshots to 1 for your Artifactory local repository. See here.
"The maximum number of unique snapshots (of the same artifact) to store. Any number of snapshots above the max are automatically removed by age."
Hope that helps!
Related
There is a job controlled by Development team which built in a different node. I am on Testing team who want to take the artifacts and deploy on test device.
I can see those Artifacts from dev are stored in some path in dev's node. Does it means it must first archived in Jenkins master before I can copy it to my job?
I am using Copy Artifact plugin and constantly getting the error
Failed to copy artifacts from <dev-job> with filter: <path-in-dev-node>
*Some newbie question since i just moved from TeamCity
You probably want to use: Copy Artifact plugin.
Adds a build step to copy artifacts from another project.
Consider also, the Jenkins post-buid step "Archive the artifacts".
If you copy from the other job's workspace, what happens if another job is in progress or the workspace is wiped? That step copies them from the node to the master and stores a copy along with the build logs, etc. That makes them available via the UI as long as the build logs remain. It can take up space tho.
If you do use archive artifacts, consider using the system property jenkins.model.Jenkins.buildsDir to store all the build logs (and artifacts) outside of the jobs config directory. Some downtime and work required to separate the two (config / logs) .
You may also want to consider using a proper repository manager (Nexus / artifactory)
Finally, you may want to learn about using a Jenkins pipeline rather the relying on chained jobs, triggers or users and so forth. Why? 'cos it's much more controlled and easier to maintain.
ps: I'm not a huge fan of artifactDeployer, but it may work for you.
pps: you may want to review this in depth answer: Jenkis downstream job fails to find upstream artifacts
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
I have curren Jenkins jobs:
1. Poll -- Retrieve Latest Tag from SVN
2. Create release and archive it
3. Manual trigger -- Deploy artifact to test environment
So 1. retrieves regularly the latest SVN tag (if created), 2. builds the release (.ear files and DB scripts) and stores the artifacts with the "Archive the artifacts" post-build job, and 3. is a manual trigger job where you actually would have to press a button to deploy the release to test environment
My question is, is it possible in build 3. to somehow "select" the desired artifact? Or is it only possible to deploy the latest workspace? Thanks!
Here is a detailed explanation how to select a specific build for deployment
How to promote a specific build number from another job in Jenkins?
In short, you need to combine Copy Artifacts plugin with Promotions concept
Each commit to our code result in regression tests and deployment of a war file to Artifactory.
We would like to deploy once a day the last successfully tested war.
What would be the best way to do this? We use Jenkins as our CI tool.
If your goal is to save on storage in Artifactory, I'd suggest setup snapshot cleanup instead. You'll always have couple of last sucessfuly tested wars and you won't polute your Artifactory with too many old snapshots.
Create a second job that copies the latest artifact (Copy Artifact Plugin) from your build job and then deploys the artifact. The second job can be scheduled to run once a day.
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.