I have some debian packages, which need network access in build time
- one builds with maven, and needs to access the repositories
- the other tries to bind to 127.0.0.1 as part of some unit tests
I would use launchpad for these, but the launchpad buildd does not support any of these kinds of network operations.
I am also building the packages with travis, so I would upload only the binary packages to launchpad, but it is also unsupported.
I am looking for either a cloud based debian package builder with network access,
or a cloud-based debian package repository where I can upload my binary and source packages.
Is there any?
I think you can use Jenkins as a Continuous Integration tool. CloudBees offers Jenkins as Service, where you can just test the environment you want to see if it meets your needs or not.
Since their slaves run on a Fedora Linux machine, you can easily generate the .deb files and after that use a Debian Repository as a Service. Bintray, for example, lets you upload your .deb packages on the cloud. Bintray is a part of JFrog, so you can easily enable the JFrog service through this PaaS.
You can upload your .deb package from the command line using this command:
curl -T -uXXXXXXXXX: https://api.bintray.com/content/XXXXXXXXX/deb///
So my idea is that you could use the Jenkins instance in order to create your .deb package (build + tests), and then upload your .deb package to Bintray using the Command Line from a Post build step on your Jenkins job.
Once you have your .deb package on Bintray you can easily access to the artifactory to get .deb for your builds/tests...
The solution was the following:
For the one which needs network socket for testing:
- I build with travis and do the testing there. I post the source packages to launchpad from that build. Testing is turned off in debian/rules. This way the package builds for more ubuntu revisions simultaneosly.
For the mavis one maybe bintray would be the right answer. Now I build with drone.io, and post to sourceforge FRS, but no apt repo there.
Related
I forked ELKI from https://github.com/elki-project because I want to keep up to date with the latest development status while making my own changes and additions to the source (which I will possibly provide via pull request if it's sensible).
I followed the instructions in the README.md to package it with mvn package but there was no .jar created in elki/target/ - when checking out the release0.7.1 branch, it worked and I could start the minigui with java -cp elki-0.7.1.jar de.lmu.ifi.dbs.elki.application.ELKILauncher.
Is there a recommended way to try out the latest changes on the master?
We are currently in the process of modularizing ELKI.
But mvn package does create .jar files in elki/target/ here:
elki/target/elki-0.7.2-SNAPSHOT.jar
elki/target/elki-0.7.2-SNAPSHOT-javadoc.jar
elki/target/elki-0.7.2-SNAPSHOT-sources.jar
elki/target/dependency/elki-core-dbids-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-dbids-int-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-util-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-docutil-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-logging-0.7.2-SNAPSHOT.jar
elki/target/dependency/hamcrest-core-1.3.jar
elki/target/dependency/javaparser-core-2.3.0.jar
elki/target/dependency/junit-4.12.jar
elki/target/dependency/trove4j-3.0.3.jar
The main jar, ./elki/target/elki-0.7.2-SNAPSHOT.jar is runnable, but will only include the command line interface because of modularization - the minigui is optional now.
If you want a all-in-one bundle (as distributed on the web site), you need to enable the Maven profile bundle in addition to the functionality you want to include (e.g. mvn -Psvg,svm,uncertain,bundle package).
I'm trying to setup simple continuous integration system on my local PC. I use gradle as my build system (gradle wrapper option). One of the steps in the build process in to deploy build artifacts to a local repository (located at:
"{user_dir}/.m2/repository)". It works ok when I run it from local PC, but when it runs on Team City CI (version 9) it deploys it to a
"{windows_dir}\System32\config\systemprofile.m2\repository". This is probably some configuration issue but I couldn't manage to solve it. In the build logs I saw that it can't find the local repository in the settings.xml file. I've tried to add it but it didn't help. How can I configure Team City to use local repository folder in user directory?
I found out what was the issue. If you install Team City system services to run under admin account it will always use windows directory. In order to use the User's directory you need to install the services under that user account.
Source: https://confluence.jetbrains.com/display/TCD9/Maven+Server-Side+Settings.
So, I'm writing the build and the deploy scripts. To create the build, I used ant. The continuous build is done with Jenkins.
The build generates 3 different artifacts:
The war file
A zip with layouts
A zip with images
So far, so good, but now I need to write the deploy script, which should:
Deploy the war (artifact 1) to the tomcat running at server 1
Place the artifact 2 at server 1 in a specific directory
Place the artifact 3 at server 2 in a specific directory
So I was talking with my colleague and he said that we should also generate an artifact (maybe deploy.xml) that deploys these artifacts when placed at the correct server.
So there would be another script, that would:
Download the jenkins artifacts
scp to each server and place the deploy.xml there
remotely invoke the deploy.xml
What makes me a little uncomfortable is the act of having the deploy.xml as a build artifact. The motivation behind this would be to be able to make a deploy without needing to have access to the VCS repositories, so a build would be self-contained, ie, any build could go into production only with what was generated by Jenkins.
Where should the deploy scripts be placed? Should they be only at the VCS or should they be build artifacts too?
Please provide if any sample deploy scripts
I wrote my own deployment framework, consisting of different shell, batch, python, and .... scripts. It neatly separates environment information from application information and allows me to quickly update deployment information and add new apps or environment. However, the orchestration of the different parts is done by Jenkins. When just copying files to a Windows server, my Jenkins master (running on Windows) just copies the files to a network share that exposes the target directory. Services I can restart remotly using sc.exe. When crossing the borders to AIX, I use jenkins slaves that are started via ssh on the target system. So distribution is managed by Jenkins. The actual work is done by the scripts.
I tried to install websphere application server for developer v8.5. I've already installed the installation manager. Then I download the image from here: all the three parts of WebSphere Application Server for Developers, Installation Manager Repository. Cause my linux has no GUI, so I unzipped the file and tried to use installation manager to install it.
I used :
./imcl listAvailablePackages -repositories /home/user/tmp/wasdev_installer/repository.config to verify that the package exist.
Then I ran : ./imcl install com.ibm.websphere.DEVELOPERSILAN.v85_8.5.5000.20130514_1044 -repositories /home/user/tmp/wasdev_installer/repository.config -installationDirectory /home/user/Websphere_v85 -accessRights nonAdmin -acceptLicense
But I always got errors like :
ERROR: The silent installation process does not support
installing packages that are contained on multiple media discs.
CRIMC1017E ERROR: Failed to locate zip com.ibm.websphere.batch_136_all.all 8.5.5000.201305110146.
Cannot find the table of contents file for an artifact in the repository. Table of contents files are located under the atoc directory in the repository.
If the repository files were transferred from a different location, verify that the files were not altered during the transfer operation. Copy the repository files to a different location and install from that location.
I re-unzipped the file, but didn't help. Was I doing wrong? Thanks for your help.
Deepending on what programming models you're using, you could always try the WebSphe Liberty Profile artefact install: https://www.ibmdw.net/wasdev/downloads/. It doesn't support every programming model that the full profile does, but it's a super-easy install, and easy to get going with as a development environment.
I resolved this issue by unzipping all files to one directory. The file part1 contains disk1, so the other files should be put under the directory of part1, which means in the same level of disk1 directory.
If you do not want to bother with downloading and decompressing archives containing the Installation Manager repositories, then there is a much easier and simpler process for getting WebSphere Application Server for Developers installed.
Once you have IBM Installation Manager installed, you only need to provide the repository location to where the IBM hosted WebSphere Application Server for Developers repository is located. For instance, to install WAS for Developers version 8.0 or version 8.5, you simply add one of the repository locations to the repository preferences.
V8.0: http://www.ibm.com/software/repositorymanager/V8WASDeveloperILAN
V8.5: http://www.ibm.com/software/repositorymanager/V85WASDeveloperILAN
Instructions for installing WAS for Developers using IBM hosted repositories in available on WASDev.net.
You could even use the IBM hosted repositories in your command line installation or response file installation, as long as you create a secure storage file with you MY IBM ID credentials for authenticating with the IBM servers, as described in the WebSphere Knowledge Center.
Alternatively, you can use the IBM Package Utility (a companion to Installation Manager), to reconstruct the IBM hosted repository on your local machine. The advantage to using PU is that you will be able to create a local repository that also includes the fixpack level of your own choosing rather than having to go get a fixpack from IBM Fix Central and then updating the installation afterwards.
Information on creating local repositories with Packaging Utility is available in the WebSphere Knowledge Center.
I am developing a simple command line application. I would like to use CloudBees to:
Git repo (OK, even a private one)
Jenkins Continuous Build (OK, trigger the build when I push to the repo, perfect)
Deploy to RUN#Cloud (OK, but painful SDK installation)
My question would be: is there a way to deploy a Java App (not a Web App) with the Maven CloudBees plugin ? (It is also to record my experience).
Running a raw Java container is documented: http://developer.cloudbees.com/bin/view/RUN/Java+Container
The bees-maven-plugin is documented here: https://developer.cloudbees.com/bin/view/RUN/MavenGuide . But the plugin does not seems to do all what the SDK can do. So I couldn't use it in Jenkins.
What I did is adding a "Script Shell / Post build step" in the Jenkins job. With the following script:
. /private/brnvrn/scripts/setup-sdk
bees app:deploy -a brnvrn/gdataaccess -t java -R class=com.brnvrn.test.Main -R classpath=gdataaccess.jar target/gdataaccess-1.0-SNAPSHOT.jar waitForApplicationStart=false
How to install the SDK in Jenkins is explained here: http://wiki.cloudbees.com/bin/view/DEV/Scripting+Bees+SDK+in+Jenkins and here is how to mount DAV directory: http://wiki.cloudbees.com/bin/view/DEV/Mounting+DAV+Repositories. (Just be aware that the files you upload in /private/ will be available in /private/$account_name/ ...
I managed to make it work and then realized that there is really no point to deploy a command line App to RUN#Cloud. Still I would like to known if the bees-maven-plugin would be able to do the job without all the SDK installation trouble.
The CloudBees maven plugin only supports deployment of WAR files. As an alternative, you can use the CloudBees Deployer plugin for Jenkins to setup a post-build action to deploy the JAR artifact (this is pre-installed in DEV#cloud Jenkins instances). You can also use the CloudBees SDK to deploy your JAR artifact (bees app:deploy -a APPID JAR_FILE)