I work on a maven project but don't have the rights to deploy in the our company nexus (this is done by the CI tool). However, while configuring deployment, I would like to test what is actually deployed by "mvn clean deploy".
Q: Is there a way to run deploy but don't send anything to the nexus repo?
I would expect 1 of 2 options:
there is some kind of dry-run option in deploy for that purpose
there is an option to redirect deployment to some local folder that acts as nexus repo (and thus can see what would have been deployed)
Note: my project is multi-modules.
I guess you could just overwrite the <distributionManagement> with a local folder:
<distributionManagement>
<repository>
<id>local-release</id>
<url>file:../local_repo/release</url>
</repository>
<snapshotRepository>
<id>local-snapshot</id>
<url>file:../local_repo/snapshot</url>
</snapshotRepository>
</distributionManagement>
Related
I currently have artifactory set up on my jenkins pipeline correctly. I can see that it does indeed fetches artifacts but I noticed there is a few artifacts that arent being pulled. These artifacts dont seem to be in my jfrog server but i do specify in the POM file where they can be found and pulled. Here they are:
<repository>
<id>osgeo</id>
<name>OSGeo Release Repository</name>
<url>https://repo.osgeo.org/repository/release/</url>
<snapshots><enabled>false</enabled></snapshots>
<releases><enabled>true</enabled></releases>
</repository>
<repository>
<id>osgeo-snapshot</id>
<name>OSGeo Snapshot Repository</name>
<url>https://repo.osgeo.org/repository/snapshot/</url>
<snapshots><enabled>true</enabled></snapshots>
<releases><enabled>false</enabled></releases>
</repository>
I guess maven/jenkins only checks my artifactory server and doesnt reach out to these repos at all. Is there a way where I can tell maven to not just look in my artifactory repo and also look in these repos as well? I have this snippet of code in my main pom file so im clueless as to why it doesnt pull from them.
Artifactory does reach out these remote endpoints if they are configured. Check if these "https://repo.osgeo.org/repository/snapshot" and "https://repo.osgeo.org/repository/release" are configured in the remote repository and if not, create the maven remote repositories in Artifactory and point the URL textbox to these remote endpoints. Add these 2 remote repositories in the Maven virtual repository and try to pull from Artifactory.
I have web project which I am going to deploy to nexus repository after successful build on jenkins. Currently in project in pom.xml I have following configuration as below where host and port to nexus repository is hardcoded:
<profiles>
<profile>
<id>deploy-snapshot</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<distributionManagement>
<snapshotRepository>
<id>snapshots</id>
<name>Repository for snapshots</name>
<url>http://ip1:port1/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
</profile>
</profiles>
My goal is override nexus url from jenkins without any changes in pom.xml, because currently that configuration in pom.xml is used on another environment which cannot be reconfigured.
It would be good to know in which way it can be done on jenkins taking into account that in future I am going to make similar for other job which will be in charge of deploying npm packages.
I've looked into following jenkins plugin https://wiki.jenkins.io/display/JENKINS/Nexus+Artifact+Uploader, but not sure that this one is actual one, also not sure that plugin will be good for zip archives for npm build.
That was requested in 2008(!) with Make the issue 295: "distributionManagement.site.url configurable from the command line"
In your case, check if passing the property altDeploymentRepository would help:
-DaltDeploymentRepository=...
More precisely, as in "Maven deploy:deploy using -DaltDeploymentRepository"
-DaltDeploymentRepository=releaseRepository::default::http://your.repo.url
"defaut" is the maven2 layout ("legacy" is for maven 1)
In order to overwrite it, you can set it in settings.xml file
In the version of Jenkins I'm using, which is ver. 1.602, if you configure your project as a Maven project, you can specify a "Deploy artifacts to Maven repostitory" post build action for which you can indicate the destination repository.
I have copied all contents from an old Nexus server to a new server. I am able to login to the new server, see all the uploaded artifacts, etc.
On the Jenkins build master, the maven builds are running obviously as the jenkins user. The home directory for that user is /var/lib/jenkins. Under there, I have copied the .m2 folder and changed all the old URL's in the settings.xml to point to the new URL.
However, when I run a maven deploy, while the build downloads some dependencies from the new nexus server, at the end of the build comes the mvn-deploy plugin and that tries to upload to the old server.
Do the artifacts, war, jar files have a record of the nexus server? Is there some setting in Jenkins that I'm missing? I did a grep for the old nexus address in /var/lib/jenkins folder and none of the config xml's have any mention of the old nexus.
Is the URL hardcoded in your pom? Maybe the pom is not using the params you set in the settings.xml?
The repositories configured in the settings.xml are the source of Maven artifacts. The destination for new artifacts is in the distributionManagement block. This is usually somewhere in your POM, or in a parent POM. The block will look something like the below. Chances are, the old URL is there.
<distributionManagement>
<repository>
<id>releases</id>
<name>Release Repository</name>
<url>${repository.url}/nexus/content/repositories/releases</url>
<layout>default</layout>
<uniqueVersion>true</uniqueVersion>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshot Repository</name>
<url>${repository.url}/nexus/content/repositories/snapshots</url>
<layout>default</layout>
<uniqueVersion>true</uniqueVersion>
</snapshotRepository>
</distributionManagement>
My versions:
Maven 3.0.4
Jenkins 1.499
Nexus 2.2
maven-release-plugin 3.2
jdk 1.6
AIX 6.1
settings.xml
<server>
<id>snapshots</id>
<username>deploy</username>
<password>pass123</password>
</server>
<server>
<id>releases</id>
<username>deploy</username>
<password>pass123</password>
</server>
I have a lot of builds running in Jenkins which use the maven deploy plugin and upload artifacts to the Nexus repo. Since the same user is able to deploy snapshots we can eliminate user roles/permissions issue in Nexus. (I still gave admin role to this user for testing)
Company parent POM
<distributionManagement>
<repository>
<id>releases</id>
<url>http://myserver/repositories/releases</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>http://myserver/repositories/snapshots</url>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>
Project POM
<scm>
<connection>scm:svn:http://svnserver/tags/1.2.3</connection>
<developerConnection>scm:svn:http://svnserver/tags/1.2.3</developerConnection>
</scm>
I have confirmed the /target/checkout/ in the Jenkins workspace contains the latest POM. Also added <distributionManagement> inside the project POM
Now when I run maven release plugin from within Jenkins using mvn release:perform I am still getting this:
Deployment failed: repository element was not specified in the POM inside
distributionManagement element or in -DaltDeploymentRepository=id::layout
::url parameter
release:prepare shows no errors
The SVN tag gets created as expected
Then during deploy, it fails with the above error
Like I mentioned, snapshot deployment happens frequently and without error, so settings.xml, distributionManagement and Nexus permissions all seem to be in order.
I am able to access http://myserver/repositories/releases manually
I have checked with mvn help:effective-pom and mvn help:effective-settings and things seem to be in order
Any ideas ?
The error message is very explicit. There is NO distributionManagement in your POM. So you potentially are no inherting from the parent pom.
Run
mvn help:effective-pom
in the project you are trying to deploy and check. Or alternatively look at the effective POM in your IDE (Eclipse or whatever).
Then figure out the correct parent pom to use or potentially insert the distribtionManagement segment as desired.
I was curious about how to set up development vs production maven profiles. Should I only put the snapshots repo in the dev profile, and the other artifacts (local repo, for releases etc), in the production profile?
What are the major things which different profiles of these types?
The major difference is, obviously, settings among Prod, Test, and Dev profiles. Things like
Database connectivity
Properties like resource settings, thread-pool configuration, log file location and it's size
Storage settings like for local you might have a /mnt/media but for Prod, you may want S3
varies in these profiles.
Now come to release, usually Test profile/s has SNAPSHOT releases (like nightly builds) that is configured to go to SNAPSHOT repository of yours. And a Prod profile is released, usually, using Maven Release Plugin, that automatically knocks the SNAPSHOT off your release version/artifacts. And is configured to store the artifact in RELEASES repo. The configuration for these repos goes like
<profile>
<id>test</id>
<distributionManagement>
<snapshotRepository>
<id>snapshotrepo</id>
<name>Repository for snapshots only</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/snapshots</url>
</snapshotRepository>
</distributionManagement>
.....
.....
.....
<profile>
<id>prod</id>
</distributionManagement>
<repository>
<id>releaserepo</id>
<name>Final release artifacts</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/releases</url>
</repository>
</distributionManagement>
....
....
The credential to these repos goes into settings.xml.
Dev profile is usually not configured to release to company repo (as it will be too cluttered of useless artifacts), it just gets installed in your local repo, as SNAPSHOT and overwritten on each build.
Usually (in my experience) the different repos are configured in settings.xml, and not in separate profiles (except maybe in profiles enabled by default).
Example of a default profile:
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>central</id>
<url>http://some_url/content/groups/public</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url>http://some_url/content/groups/public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
If you are concerned about having SNAPSHOT dependencies in your releases, you can use tools like maven-release-plugin to verify that there are no SNAPSHOT dependencies in your project.
What are the major things which different profiles of these types?
You often use profiles to separate between different build environments. For instance, using a CI you often put plugins for static code analysis, reporting, test coverage etc. in a profile that is only activated when building on the CI server (since it takes more time to run it with these tools enabled).
Another use is to separate out specific part of the application, for instance you don't want the acceptance-test submodule to run on every mvn test, but only sometimes when you enable the mvn test -p acceptanceTests profile
The problem with environment specific builds
Now, profiles are sometimes used to separate configurations like connections strings, enpoints etc. In my view that is not ideal, since you end up with environment specific builds. Sometimes that is hard to avoid, but most of the time this can be solved by externalizing configuration (make sure to have proper configuration management), and use the same binary artifact in dev/test/prod. That way you are sure that the build that passed system test is the same as that in prod etc.