I'm getting started with Artifactory and am getting confused by all the terminology. What I'm trying to accomplish is the following:
$ git clone https://github.com/apache/hbase.git
$ cd hbase
$ git checkout branch-1.2
$ mvn clean install -DskipTests assembly:single
I'd like the git clone of this upstream project to live in Artifactory along with the components that Maven is pulling down. Additionally the final product zip file that mvn builds, hbase-assembly/target/hbase-1.1.6-bin.tar.gz, I want to store that in Artifactory too so that we can use it downstream in several CI jobs.
Questions
Is this approach correct?
How do I accomplish this?
Artifactory provides you with the Remote Repository functionality which you can also use to proxy various VCS services although I fail to see the point in just storing a clone of a git repo in Artifactory -
The VCS remotes are mainly used for cases where you directly include source code that you don't need to influence in your own code (i.e you can't git push changes back into Artifactory - they will not be persisted in the upstream git repo).
If you're aiming to have your CI job clone a certain branch, run tests, build it and then deploy build artifacts back to artifactory, I would suggest configuring your job to clone the git repo (using git not Artifactory) and then deploying the build artifacts back to Artifactory for downstream jobs to use.
Artifactory provides very extensive integration with popular build servers through which you can achive what's discussed here, your build artifacts should go into a Maven repository and the downstream jobs should reference it with their own pom files - you can quickly setup any Maven client to work with Artifactory using the Set Me Up dialog.
Related
I've a valid local maven repo which is generated by a closed-source tool. I'd like to deploy the full repo to a remote maven repo.
Any clues how to do this ?
If you can't scp or transfer up the repo another way, then I assume you'd have to write a script that would walk your local repo and put them all up using the deploy plugin.
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
If you're moving the whole repo up, I'd suggest to put it to an isolated repo so that it doesn't mix with other upstream repos like central.
We are planning to implement continuous integration with Jenkins software, so we successfully installed Jenkins in our server (windows platform)
My question was
How can I manage (keep) my source code?
How can we configure if the source code located in some other machine / server / cloud
Our current process
Jenkins, source code is available in same machine, so we created a project in Jenkins and map the pom.xml (like D:\pom.xml) file under build section.
Choose a Version control tool, consider that SVN and GIT are quite different (Git--> Distributed system, SVN-> Centralized system) so read a bit about them before choose, then check for the availability of GIT/SVN plugin in Jenkins unless it already contained in your Jenkins installation.
Put the code under SVN/GIT, follow the standards, configure Jenkins in order to access to SVN/GIT server.
Check how to configure maven with Jenkins, it has a great integration with Maven.
Maven Jenkins:
https://www.tutorialspoint.com/jenkins/jenkins_maven_setup.htm
Jenkins Git:
Jenkins and Git sparse checkouts
The flow of the single build job is:
Checkout The code,
Specify the folder with the pom.xml file
Run the maven goal you need (e.g. mvn install)
You put your source code into Subversion or Git. Then you give your Jenkins access to the Subversion/Git and point it to the URL which you want to checkout.
Answer to first question : Host your code in a SVN or GIT repository. Git has higher market share than SVN because of large feature set and higher efficiency. SVN is simple and easy to use for new comers in the version control territory. Explore the options and host the corresponding server in your infrastructure.
Answer to second question : There are multiple plugins available in Jenkins to fetch code from remote repositories. For git , there is git client, gitlab and gitHub plugin . For SVN there is Polarion webClient for SVN 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.
Is it possible in someway to configure my build job such that rather than picking maven artifacts from the central repo , it picks them from the local maven repo. residing on my system?
NOTE - I want others to be able to run build jobs via jenkins , while pointing to my fusion repo.
Thanks
If you want to share a maven repository with multiple users I recommend to use a repository manager see maven repository management. The mostly used once are Artifactory and Nexus. This can handle the central repo as well as own managed repositories by ThirdParties or by your self. They also work as proxy to reduce the bandwidth used in your organisation.
Much easier method to achieve local-only maven builds.
Just use the offline flag (-o):
mvn -o clean package
Maven will build off your local repo directly and will not pull down updates.
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!)