Were you able to get anywhere with figuring out how to get Bamboo to pull artifacts from Nexus using the maven 3.x artifact download?
You need to have the version number available, possibly in a property file that can be injected into Bamboo in a previous job or step.
Then use a Maven 3.x Bamboo Task with the Goal set to:
-B dependency:unpack -Dartifact=your_group:your_artifact:${bamboo.inject.version}:jar -DoutputDirectory=.
The -B indicates non-interactive of batch mode, -DoutputDirectory can be set to anywhere you want it.
You will also need to place your nexus URL as a mirror in the settings.xml file in the .m2 directory of the bamboo os user.
Related
In out project we are using using deployed war file in /archiva-2.2.0/repositories/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war path using shell script to copy to jboss. However finding the latest build timestamp and build number is very difficult. Is there a way to avoid using timestamp while storing it in archiva like proj-1-SNAPSHOT.war?
I have already read about <uniqueVersion>false</uniqueVersion> whcih is not supported in maven 3.
I am using archiva-2.2.0, maven-3.3.9.
Maven repositories wasn't designed to distribute deployable components, your continuous integration environment should take care of this. Jenkins has eg Archive Artifacts (native) and Copy Artifact Plugin which you can use to store and recover binaries in your pipelines.
But you can workaround this behavior changing the version of the war to a stable one - removing the -SNAPSHOT suffix. This will lead you with a predictable URL.
I am posting this as it is a new finding, if I wget http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-SNAPSHOT.war. I get the latest deployed artifact in the archiva repository. So archiva does a 302 redirect to point to url of http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war location and downloads the latest build. I am not sure if this works for other repositories like nexus or artifactory etc.
Ofcourse I will need a cron job to periodically clear of the stale snapshot artifacts.
we are using the Maven Wagon SSH and Wagon SSH External plugins to deploy to our nexus repository. This way artifacts in the nexus can be overridden.
Is there a way to prevent this on the maven side? Or do we have to change either the wagon or the file system permissions for the artifacts?
I would suggest you to use the deploy command or use maven-release-plugin. With the plugin you can prepare your pom.xml to next version and it will commit these changes to your version control (git,svn). Then you can run perform command to build prepared version and deploy it into the nexus.
The point is you can re-deploy your working snapshot version (that ends with -SNAPSHOT) as much as you want. But you can deploy version WITHOUT snapshot only once. That ensures you the release version wont be overridden this way!
The problem is you have to update your version manually or you will use that mentioned plugin.
I am in a situation where I have one Build Server box which is to carry out all continuous integration and manage our maven repository. The box works as follows:
There is one maven repository which is hosted through Apache Server as a URL for developers to use
All Jenkins jobs (including release jobs) run mvn install so that artifacts are kept in this one repository.
I would like to get rid of the Apache server and run Nexus on this same box to manage and host repositories, however I have the following questions/ideas:
With Nexus and Jenkins on the same box, will it mean that I will have to manage two repositories, one where maven installs an artifact to a local repository, and one where maven deploys an artifact to nexus? Would it be possible to have Nexus manage the "mvn install" repository also? How can I make sure we don't run out of disk space on the server very very quickly all the time?
Thanks
Added as response to comments: Thank you both, I am thinking I will just set the Jenkins jobs and release plugin goals to mvn package deploy:deploy in order to skip the install phase, that way, artifacts go directly from the target directory to Nexus. However I guess the Jenkins job will require a local repository from which to use depedencies which will get copied from Nexus to the maven local repository during the build, I am not sure if this can be avoided though.
mvn install installs in the local repository
mvn deploy installs to the remote repository
these semantics are defined in the lifecycle and map to different plugins. Their implementations are different.
You don't have to manage the local repository. Actually for some if not most jobs you might even want to define it localized to the job (with the 'Use private Maven repository' option) instead of to the user who is running the job, especially that you plan to use nexus for repository.
You will have to change your jobs to use mvn deploy instead.
How can I make sure we don't run out of disk space on the server very
very quickly all the time?
Configure Jenkins/Nexus. Discard old builds and disable automatic artifact archiving. Both settings can be found in the Jenkins job-configuration. Also you could delete old artifacts automatically from Nexus using Scheduling Tasks.
There is no need to install the artifacts into the local maven repository when using Jenkins/Nexus on a dedicated server.
My current Jenkins deployment job retrieves war file generated from maven build process from Nexus repository. The deployment is done this way since I can not use hot deployment for my environments. Currently I used parameterized build with Jenkins so I can manually enter the version number for my artifact. Is there a way to configure Maven or Nexus so the artifact generate from the latest trunk build can be accessed from an static URL? For example:
http://mynexus:8081/nexus/content/repository/snapshots/com/somepackage/my-app/trunk/my-app-trunk.war
I don't know a way to do this in Nexus. But you can access the latest successful build from Jenkins, with a URL like this: http://localhost:8080/jenkins/job/jobname/lastSuccessfulBuild/my-app-trunk.war
You have to enable artifact archiving for your war file, then you can access it.
Same issue here, we discovered about :
https://wiki.jenkins-ci.org/display/JENKINS/Maven+Deployment+Linker
Which does the job.
Hope that helps.
I'm trying to setup a complete CI server, but I struggle on some points.
Currently, my system work as follow :
I commit local changes on my local GIT repository, then push to the GIT repository on the CI server
I then have a jenkins job triggered by the SCM change, who run a clean install and by doing so executes all my Junit and Jstestdriver test (via a local jstd server). This job deploy the snapshot artifact to a repository on my nexus repository
I installed M2-release-plugin for jenkins, and setup my pom.xml accordingly using maven-release-plugin. When i click on "Perform maven release" in jenkins job page, jenkins run mvn release:prepare release:perform, thus creating a tag in my git repo (say v000001) and deploying a versionned artifact on my nexus repository.
I don't really know if this process is fine, but i guess so...
My problem is that I want to deliver the versionned artifact in my nexus repo (say "artifact-v0000001.war") in my production tomcat. But I can't figure out how to do it.
When I do "mvn release:prepare release:perform tomcat:deploy" it deploys the new SNAPSHOT artifact built ... I don't want to do this, I want to reuse the artifact from the nexus repository.
Is there a way to doing this using a tool (maven/jenkins plugin, or external)?
Basically, I want to fetch the last release artifact on the repository, and send it to the tomcat manager for dereploying the webapp.
Do I need to setup a delivery job separated from the release job?
Jenkins, especially when combined with a tool like ANT, can do just about anything. It has a lot of plug-ins, and you can always write a script and incorporate it into a Jenkins build. Currently, I use Jenkins to deploy web applications to Windows IIS servers. What you could do here is have a Jenkins build that has your SVN path set in the source control section so that it fetches the latest version when you trigger the build. From there it should be fairly trivial to write an ANT script that copies it over the existing JAR in Tomcat, which will automatically restart it.
Your problem is that you are probably using the Jenkins release plugin, not the "m2 release plugin". The problem with the standard plugin is that it performs the regular build, saves the artifacts, then performs the release. It will then try to deploy the wrong artifacts that it created from the regular build.
The m2 release plugin solves this particular problem. There are some tricky workaround for this problem, but that's how it stands at the moment until this feature is implemented: https://issues.jenkins-ci.org/browse/JENKINS-11120 (log in and vote for it!)