I am trying to build and CI environment and I think that it works because I can publish a jar into Nexus automatically.
Git
BitBucket
Jenkins
Nexus OSS
I am looking information about the deployment of maven projects automatically when it publish to nexus , but I am not sure about my initial idea.
My initial idea is to download the latest artifact from Nexus3 and use mvn spring-boot:run but I am not sure about my decission.
I read information about Puppet but I am not sure about this option, could anyone help to me about this process ? Or send to me another link in the StackOVerflow about this problem.
Regards !
Build a pipeline in Jenkins:
First job builds an artifacts and uploads it to the storage (in your case it's Nexus). It has to determine which version it uploaded - the easiest way to do that is to set the version by the job itself and then upload the known version (see a sample script at the bottom).
Then pass the known version to the downstream jobs (like deploying to envs). You'd need to tell Jenkins which version you just deployed - it's possible to write it into a key-value file and then use something like EnvInject plugin to read it as an env var.
To download an artifact from Nexus use wget/curl:
http://nexus.domain/nexus/service/local/artifact/maven/redirect?r={repository}&g={groupId}&a={artifactId}&v={version}&p={type}
Jenkins has several plugins for building pipelines, but you can start with a simple built-in possibility of jobs to invoke other jobs.
Couple of notes:
Do not use Maven for deployment. Maven is a build tool, it's not suitable for deployments. Write bash scripts and possibly use Docker for deployment automation.
Do not use LATEST/SNAPSHOT/RELEASE versions - you need to have a deterministic deployment (if it's repeated with the same params it deploys the same artifact).
A sample script that sets a snapshot-like version (so it's possible to upload the artifact to snapshot Maven repo):
VERSION=`mvn help:evaluate -Dexpression=project.version | grep -v "^\["| grep -v Download`
VERSION=${VERSION/%-SNAPSHOT/} #get rid of -SNAPSHOT if it's there
VERSION="$VERSION-"`date +"%Y%m%d.%H%M%S"`"-$BUILD_NUMBER"
mvn versions:set -DnewVersion=$VERSION
Related
OpenDaylight Oxygen
Maven 3.3.9
Ubuntu 16.04
karaf 4
~/.m2/settings.xml - cp -n ~/.m2/settings.xml{,.orig} ; wget -q -O - https://raw.githubusercontent.com/opendaylight/odlparent/master/settings.xml > ~/.m2/settings.xml
Process used to create skeleton
mvn archetype:generate -DgroupId=org.opendaylight.controller -DartifactId=testing -Dcopyright="None" -DclassPrefix="\${artifactId.substring(0,1).toUpperCase()}\${artifactId.substring(1)}" -DarchetypeGroupId=org.opendaylight.archetypes -DarchetypeArtifactId=opendaylight-startup-archetype -DarchetypeVersion=1.1.0-SNAPSHOT -DinteractiveMode=false
mvn clean install -Dcheckstyle.skip
I'm trying to build a sample app and deploy it on a separate instance of ODL (karaf 4). I cannot find a working answer to this anywhere.
I've tried copying the contents of PROJECT/karaf/target/assembly/system/org/opendaylight/controller to the equivalent folder on the other ODL instance. Then used feature:add-repo to add the feature. It was able to detect the plugin, but feature:install odl-testing failed to install.
Any help would be greatly appreciated.
You are not showing what exact failure you hit when you say "feature:install odl-testing failed to install", but FYI most people don't actually use the process you are trying to get working.. it's technically possible to build your new bundles and Karaf feature separately and then manually add it to deploy on a separate instance of ODL... but every project I know of finds it easier to just let the build produce a ready-to-use Karaf distribution.
You have probably seen the distro in karaf/target/assembly which the the ODL archetype (documented here BTW; note the use of archetypeGroupId changed to org.opendaylight.archetypes in the just released latest Fluorine version) produces?
So what you can do instead is to just add your "base" feature which you are presumably wanting to add your feature into as a dependency to your custom feature. With this, you get your ready-to-run custom distribution including your new code and whatever other ODL features you want to include.
We have a scenario to deploy the artifact generated from maven build to Nexus. The Jenkins job would run goals clean package. The artifact should go to SNAPSHOT repo if the pom.xml has a SNAPSHOT version. If the pom.xml has a release version, the artifact should go to release repo. Any idea how we can achieve this using the Deploy to Maven Repository plugin. As of now I am using the below script in Execute Shell.
#!/bin/bash
var1=$1
var2="SNAPSHOT"
if [[ $(echo "$var1"|grep -i "$var2" | wc -l | tr -d ' ') -gt 0 ]]; then
exit 1
else
exit 0
fi
In Flexible Publish post build action, I am using Execute Shell conditional action. Based on the result of the script, I would execute the Deploy to Maven repository post build action. This can only help to deploy to release repo. Any better way of doing it.
I assume that if you cannot update pom files in repositories, you have two options:
There is a Maven Project plugin, which allows you to add a new post-build action Deploy artifacts to Maven repository. It allows you to set repository URL and name, along with few other options. Setting repository with snapshot policy as a target one will result in successful upload of snapshot artifacts. Note that
the step is available only if build type is Maven build (2/3)
upload will fail with Bad request error if you try to upload release artifact
In case adding a plugin is not an option, you can use dirty hack and alter pom file on-the-fly as the first build step via something like sed. That's risky and should not be used if not absolutely inevitable.
To update all builds at once I'd recommend either use some plugin (Configuration Slicing plugin as an option) or alter config.xml files directly via script from CLI and then use "Reload configuration" in Jenkins.
I believe that this functionality is built into Maven itself; you can specify a different <repository> and <snapshotRepository> in your <distrobutionManagement> block. (See docs)
How can I automatically deploy a war from Nexus to Tomcat?
I have a maven web project which gets built and deployed (both SNAPSHOT and release versions) on Nexus successfully. I would like to know if there is feature/plugin in Nexus where it picks the released war and deploys on remote Tomcat automatically?
I know that you can deploy the war to remote Tomcat using maven-tomcat-plugin but would like to know if there is an alternative solution.
Please guide.
Typically you'd use a CI tool like Jenkins to run the Maven build that publishes your War file into Nexus. Nexus would then be used by whatever tool you're using to push the War onto the target tomcat environment:
There are lots and lots of options.
Jenkins post build SSH script
Run a post-build SSH task from Jenkins that does something like this on the target tomcat server:
curl "http://myrepo/nexus/service/local/artifact/maven/redirect?r=releases&g=myorg&a=myapp&v=1.1&e=war" \
-o /usr/local/share/tomcat7/webapps/myapp.war
service tomcat7 restart
Rundeck
My preference is to use Rundeck for deployments, because it has a Nexus plugin, providing convenient drop-down menus of available releases.
There is also a Rundeck plugin for Jenkins that can be used to orchestrate a CI process with Jenkins performing the build, hand-over to Rundeck for deployment, followed by a Jenkins call-back to run the integration tests.
Chef
I also use chef which can be used to automatically deploy software in a pull fashion.
The artifact cookbook has direct support for Nexus, whereas the application_java cookbook uses a more generic "pull from a URL" approach that also works well.
..
..
The list goes on, so I hope this helps.
We used UrbanCode for the deployment automation, retrieves war from Artifactory/Nexus and deploy to the target server.
I used the Nexus Rest-API, these endpoints downloads the artifact to Jenkins workspace.
In order to deploy Snapshot & Release to Tomcat we can create a Jenkins parameterized job and pass the parameters to the REST endpoint, also to deploy to a server like Tomact "Deploy WAR/EAR" Jenkins plugin will help.
We can parameterize the endpoint and use as part of "Build" step along with "Execute Shell script" option for the build.
wget --user=${UserName} --password=${Password} "http://192.168.49.131:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=${GroupId}&a=${ArtifactId}&v=${Version}&e=${TypeOfArtifact}" --content-disposition
Actual endpoints to Nexus looks something like below.
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=snapshots&g=org.codezarvis.artifactory&a=hushly&v=0.0.1-SNAPSHOT&e=jar" --content-disposition
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=org.codezarvis.artifactory&a=hushly&v=0.0.5&e=jar" --content-disposition
Thanks
-Sudarshan
I'm in a team to develop plugins in java.
We got Maven, a repository and Jenkins,
And I got myself a debian-server to test my applications.
When I push my commits, this happens:
Push in repository, upload and build in Jenkins.
Users download these .jar files and upload these to their server
What I want to be happen:
There are two ways,
First: After building with Jenkins: Download these files,
Second: When pressing "maven build", maven builds my applications and copy these to my server
How can I do this?
(Sorry for my bad English: I'm German)
If I understand you correctly, following scenario should help.
create two jobs
first job builds your artifact and archives it: user will be able to download it, job is triggered by source modification
second job is only executed manually (and requires two plugins, listed below), copies artifacts from first job and then uploads them to the server
Following plugins you would need to install:
copy artifact plugin to enable jenkins to copy artifacts from another job
publish over ssh plugin to enable jenkins to upload binaries and run commands on remote servers
You want when you push your SCM repository, to get Jenkins build into your local projet (update your jars), then manipulate send your final build to your server. Is that you want ?
If yes, I think that plugin would be interesting :
http://evgeny-goldin.com/wiki/Jenkins-maven-plugin#Supported_Plugins
you can manage jenkins goals from your pom.xml but I am not sure if you can get jenkins build.
The problem: you have a zipped java project distribution, which depends on several libraries like spring-core, spring-context, jacskon, testng and slf4j. The task is to make the thing buildable offline. It's okay to create project-scope local repo with all required library jars.
I've tried to do that. Looks like even as the project contains the jars it requires for javac and runtime, the build would still require internet access. Maven would still lurk into network to fetch most of its own plugins it requires for the build. I assume that maven is run with empty .m2 directory (as this may be the first launch of the build, which may be an offline build). No, I am not okay with distributing full maven repo snapshot along the project itself, as this looks like an utter mess for me.
A bit of backround: the broader task is to create windows portable-style JDK/IntelliJ Idea distribution which goes along the project and allows for some minimal java coding/running inside IDE with minimal configuration and minimal internet access. The project is targeted towards students in a computer class, with little or no control over system configuration. It is desirable to keep console build system intact for the offline mode, but I guess that maven is overly dependent on the network, so I have to ditch it in favor of good old ant.
So, what's your opinion, could we move first maven build in offline mode completely? My gut feeling is that initial maven distribution just contains the bare minimum required to pull essential plugins off the main repo and is not fully functional without seeing the main repo at least once.
Maven has a '-o' switch which allows you to build offline:
-o,--offline Work offline
Of course, you will need to have your dependencies already cached into your $HOME/.m2/repository for this to build without errors. You can load the dependencies with:
mvn dependency:go-offline
I tried this process and it doesn't seem to fully work. I did a:
rm -rf $HOME/.m2/repository
mvn dependency:go-offline # lot of stuff downloaded
# unplugged my network
# develop stuff
mvn install # errors from missing plugins
What did work however is:
rm -rf $HOME/.m2/repository
mvn install # while still online
# unplugged my network
# develop stuff
mvn install
You could run maven dependency:go-offline on a brand new .m2 repo for the concerned project. This should download everything that maven needs to be able to run offline. If these are then put into a project-scope local repo, you should be able to achieve what you want. I haven't tried this though
Specify a local repository location, either within settings.xml file with <localRepository>...</localRepository> or by running mvn with -Dmaven.repo.local=... parameter.
After initial project build, all necessary artifacts should be cached locally, and you can reference this repository location the same ways, while running other Maven builds in offline mode (mvn -o ...).