Currently a Maven build (inside Jenkins) is configured to deploy every artifact it builds (releases and snapshots) to a Nexus repository. Now I have to push some of those artifacts to application servers and thought of letting the target servers fetch them from Nexus - this is easy for releases but how can I reference the SNAPSHOT artifacts? Maven's deploy plugin adds a timestamp to make each artifact unique (which is good) but I couldn't find a way to get that generated timestamp for later use!
Quick Aside: I plan to use the promoted builds plugin to start a script on the target server(s) which then in turn ask Nexus for the new artifact to deploy.
Does anybody know how I can make Maven say the timestamp it generates? Or do I really have to parse the whole output for Uploaded: https://NEXUS_URL/content/repositories/snapshots/GROUP/ARTIFACT/VERSION/ARTIFACT-VERSION-TIMESTAMP-SUFFIX.TYPE?
As far as I know you do need to parse the output of the deploy goal.
Related
From Azure CI pipeline I can see that before the build/artifact upload to Artifactory, the artifact id is
my-app-0.0.1-SNAPSHOT.jar
however after Artifactory upload, it becomes
my-app-0.0.1-20211006.161121-1.jar
But another Java project don't have such behavior hence no extra data/timestamp in the artifact name.
I assume the pipeline only upload the jar file without check the pom.xml, so what can be the cause of such difference in the naming convension.
When SNAPSHOTs are uploaded to Nexus or Artifactory, the suffix SNAPSHOT is automatically replaced by a timestamp and a number.
This is perfectly normal and nothing to worry about.
I see that you can add a goal to a maven Pom to archive artifacts to a repo manager such as nexus
https://www.baeldung.com/maven-deploy-nexus
distributionManagement>
<snapshotRepository>
<id>nexus-snapshots</id>
<url>http://localhost:8081/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
But Jenkins also allows you to do this from the pipeline itself
https://wiki.jenkins.io/plugins/servlet/mobile?contentId=96076078#content/view/96076078
freeStyleJob('NexusArtifactUploaderJob') {
steps {
nexusArtifactUploader {
nexusVersion('nexus2')
protocol('http')
nexusUrl('localhost:8080/nexus')
groupId('sp.sd')
version('2.4')
repository('NexusArtifactUploader')
credentialsId('44620c50-1589-4617-a677-7563985e46e1')
artifact {
artifactId('nexus-artifact-uploader')
type('jar')
classifier('debug')
file('nexus-artifact-uploader.jar')
}
artifact {
artifactId('nexus-artifact-uploader')
type('hpi')
classifier('debug')
file('nexus-artifact-uploader.hpi')
}
}
}
}
What is the difference between the two approaches, is one more commonly used?
The main difference is that if you use maven, you can manually add artifacts to Nexus from your local computer, using mvn deploy. So it really comes down to how you want to create the artifacts that end up being used in production. In my experience, the preferred way of doing this is through using Jenkins. The advantage of using Jenkins is that you link your new version builds to other activities, as well as the possibility to trigger a release when certain conditions have been met, rather than starting the build manually. Also, you end up with all versions being built on the same platform, and you avoid differences between computers if every developer builds such versions from their own computer.
But you might still need the maven configuration. Jenkins might use this information to find the URL to upload the artifact to (your example says nothing about how Jenkins finds Nexus), and sometimes it is useful to upload a SNAPSHOT-version, or some other temporary version not meant for production. In your example you only define Nexus for upload SNAPSHOT-versions, I guess this is done on purpose to enforce a rule that uploading final version from local computers is disallowed.
By the way, having a repository defined in your pom.xml does not automatically mean that anything will be uploaded. It is only if you do mvn deploy with a repository defined in your pom that something will be uploaded.
I'm working on a strategy to tag builds in my continuous integration and delivery pipeline. When a fresh build is produced it then goes through multiple stages of testing; after each stage I would like to tag the build. My idea was to expand on the standard Maven system, so an example would be:
my-artifact-1.0-SNAPSHOT.jar
my-artifact-1.0-PASSED_TESTS_1.jar
my-artifact-1.0-PASSED_TESTS_2.jar
...
my-artifact-1.0-RELEASE.jar
As a build passes each stage its tag, which is part of its name/version, gets updated. Eventually, after all testing stages the build is tagged as releasable with RELEASE.
I'm using a Jenkins server and storing artifacts on Artifactory (non-Pro) in Maven repositories. My plan is to use separate Maven repositories for each tag type above, and to move an artifact from one to the other as its tag is updated.
My pseudo-code for the promotion looks like:
(1) Download artifacts that passed in Jenkins
(2) Text-replace the tag (maybe pom.xml as well?)
(3) Upload to new repository
(4) Update the associated Git commit with tag also
I'm not sure how to actually implement this cleanly - is this a common way of doing things? Am I missing something important? Can a Jenkins + Artifactory (non-Pro) + Maven (repos only, Gradle for builds) system accomplish this?
Thanks!
I can see where the idea of adding more metadata to the file names come. Usually, we don't have any other place to add this kind of information, except of the name. But with a proper artifact repository manager (as Artifactory), you don't need it anymore. You can attach any metadata to the artifacts in the repository manager, and then manipulate (e.g. promote) the artifacts based on those properties.
Here's a screencast showing what it takes to add this kind of metadata to the artifacts, and how to promote artifacts based on it.
We're deploying our open source libraries to the OSS instance of Sonatype Nexus (https://oss.sonatype.org/) using the nexus-staging-plugin. This works all fine and well. However, since we're using a build server I want to block an accidential re-deployment of an existing artifact id - as this is normally not suppoted by maven. However, the OSSRH happily accepts and updates an existing release. Is there any way to block this and make the build fail?
I know that Nexus can be configured to do that - it is just, that I don't have any permissions to reconfigure the OSSRH instance..
Is there any maven plugin which could check the repo first and fail in first place in case nexus/sonatype does not support this? I looked into the enforcer plugin but there isn't a rule available.
It is true that there is a staging rule in Nexus which prevents duplicate GAV's being staged, but it is not enabled on https://oss.sonatype.org. The reason for this is that some users stage artifacts repeatedly (creating multiple staging repositories) and then choose one of them for release based on testing results.
But the server at https://oss.sonatype.org is configured so that you cannot release the same artifacts twice. So if you have two staging repositories that contain the same artifacts you will only be able to release one of them.
Now that Maven3 has dropped support for setting uniqueVersion=false on deployment, I'm running into an issue. I have Hudson do an automatic deployment of my SNAPSHOT build to my Nexus repository manager. The resulting SNAPSHOT artifact looks like blah-0.0.1-20110517.233746-1.jar. Note the unique SNAPSHOT build id. The trick is that I'd link to that jar in my site documentation, but I'm not sure how to inject that snapshot build number into the docs. Perhaps there is a way to have Maven or Hudson or Nexus create a symlink on deployment from blah-0.0.1.jar => blah-0.0.1-20110517.233746-1.jar?
Ok, mod me down, but I think I found an answer to my own question. I'm posting here in case anyone else finds it useful.
It turns out the Nexus REST api has the ability to automatically retrieve the latest SNAPSHOT build of an artifact, which is exactly the functionality I needed. For more info, see:
https://docs.sonatype.com/display/SPRTNXOSS/Nexus+FAQ#NexusFAQ-Q.HowcanIretrieveasnapshotifIdon%27tknowtheexactfilename%3F