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
Related
I am not able to discard the old artifacts using artifactory plugin in Jenkins. Is there a way that, we can discard the old artifacts from Jenkins itself.
Note :- I am already using Jenkins artifactory plugin but I am not able to discard it via that.
Jenkins Version: 2.3
I tried deleting from Jenkins but I am not able to delete that.
I am expecting that old artifacts gets deleted because we are having discard old builds option available in Jenkins artifactory plugin.
I was testing to see if jenkins job's retention policy is respected by artifactory.
I created a simple Free-Style project and uploaded a build to artifactory with option selected "Discard old builds from Artifactory (requires Artifactory Pro)" and I am using artifactory PRO.
The build artifacts and metadata are uploaded and I can see the "Build info json" on artifactory.
According to json schem given under "Build info format" section here, there should be a section like:
"buildRetention" : { // Build retention information
"deleteBuildArtifacts" : true,
..
..
},
In my case it is not visible.
Am I doing something wrong.
Jenkins: 2.263.4
"artifactoryPluginVersion": "3.11.4"
artifactory: 7.4.3
and I am using generic repository.
In older versions of the Jenkins Artifactory Plugin, the build retention policy indeed uswd to be included as part of the build-info JSON. Artifactory used to read the information from the build-info JSON whenever a build-info was published, and triggered the retention. Today however, the retention request is no longer sent to Artifactory this way. Instead, Jenkins sends a separate REST request to Artifactory for the build retention, right after the build-info is published. This change decouples these two actions, and by that allows triggering the retention when desired in pipeline jobs. See for example hope this is done using the Artifactory DSL for pipeline jobs. In terms of the retention functionality, it remained the same for Free-Style jobs.
In the contest of build retention, it's also worth mentioning that in Free-Style jobs, in addition to setting the "Discard old builds from Artifactory (requires Artifactory Pro)" option in the UI, you should also configure the build retention under "Discard old builds". In this section you can indicate how long to keep old builds on Jenkins. In Free-Style jobs, this configuration is also used to discard the builds from Artifactory.
Can Artifactory be used as "SCM" or source in Jenkins to trigger the builds on an particular artifact deploy?
Don't see (or miss it) anything similar in the Artifactory Jenkis plugin description (and on Jenkins side)
This could be needed for instance if there is only access to the Artifactory repository and not to the SCM with code the binaries are coming from.
Such functionality looks to be availble for Nexus (via nexus-webhook-plugin). Hard to believe that this feature is missing for Artifactory.
It's maybe not as elegant as a hook, but I believe the URLTrigger Plugin will achieve what you're looking for. Listed in their use cases:
This plugin enables users to check if new artifacts (such as binaries) have been deployed in a repository (managed for example by a repository manager such as Sonatype Nexus, JFrog Artifactory, Apache Archiva and so on).
It allows you to check the last modification date and inspect the contents of the response for changes.
You would have to use a polling interval instead of relying on Artifactory to notify Jenkins via a hook, but in my experience polling is relatively innocuous even with lots of polls at high intervals.
Now you can use Enable Artifactory trigger in a newer version.
Go to Build Triggers and check the Enable Artifactory trigger checkbox.
More Detail on GitHub Support for Artifactory trigger
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.
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.