Remote gradle build daemon - gradle

This is in context of a CICD system. Is there any way to have a remote, long lived gradle daemon that does not live on the same box as the gradle client? I.E a daemon that I can call over the network w/ the local gradle CLI

No, Gradle does not (yet) support distributing builds to remote machines. There is a hint from the developers here that suggests that the feature might come eventually.

Related

How to avoid Gradle wrapper downloading distro when running in Gradle docker image?

My project is built with gradlew. GitLab CI builds the project in a docker runner with an official Gradle image (see https://hub.docker.com/_/gradle).
Now even though Gradle is already installed in the cointainer, the wrapper will still download the distro every time. This makes up the majority of the build time.
How can I "tell" the wrapper about the already installed distro, so that it will not redownload it (assuming of course the versions match)?
Of course the alternative is to use gradle instead of gradlew in CI and rely on the docker image to have the correct distro but I'd like to avoid this if possible, as I would then have to manually keep .gitlab-ci.yml and the wrapper config in sync.
I don't think you cant instruct the wrapper to use a local version of Gradle that was installed manually.
The only approach I can think of to prevent downloading the distribution on every build, that doesn't involve additional steps when upgrading Gradle, is to cache the Gradle home folder (e.g. /home/gradle/.gradle). This should be possible even if it resides in a Docker container.
I don't know the details of how GitLab supports caching, but it probably only makes sense if the cache is stored locally (either on the same machine or in a cache server with high network bandwidth). If it has to be uploaded and downloaded from something like an S3 bucket on every build, that would likely take as much time as downloading it from services.gradle.org. But if you can make this work, you will not only cache the Gradle distribution but also the build dependencies, which should further speed up the build.

How to get Jenkins repository server to host only stable builds?

I have Jenkins version 2.7.1 running on a Windows 7 machine. It is successfully pulling code from a subversion repository and running tests. I have the test jobs set up for the development branch of each project only.
We periodically make stable releases of the projects in jar files with version numbers. I would like to have Jenkins be the repository manager for those stable releases. These are made by hand - There is no Jenkins job making or testing stable releases. The projects do use Maven.
Each stable build is tagged in the subversion repository, so it could be made again on demand if needed.
I downloaded the Maven repository server hoping to make this fit the purpose. I read the documentation that's provided, but it's pretty terse. As I understand it and have it configured now, this appears to have a couple of issues:
If I go to jenkins-ip/plugin/repository/project, it has made directories there that expose the names of all of my projects, which seems undesirable. (Here jenkins-ip is the IP where I access Jenkins on my local network.)
On the other hand, there's nothing but empty directories under these projects, so they're currently useless.
These projects all correspond to the continuous testing of the development branch. There's no apparent way to get the stable builds into the hierarchy. (It doesn't seem efficient to create a job for each stable release...)
Is there anyway to get Jenkins (with this plugin or through another method) to be the repository manager just for the stable builds? I know that I can start a different repository manager like archiva, but it would be ideal to use Jenkins since it's already running and it seems to claim capability for this function now.
To use Maven repository server you have to build the project on Jenkins.
Then the plugin will expose all archived artifacts as maven repo.
Note you need to use a "Maven project" type for it to work (freestyle is not supported)
There are several plugins that will help you manage building from multiple tags, however not all of them work with "Maven project" type.
You could also try Jenkins pipeline (previously "Workflow") or the Job-DSL plugin.
A simplest solution would be to have a build parameter specify the tag name (then checkout e.g. ^/tags/projectname/${tagParam}), but you have to figure out how to trigger the job then.

Running load tests via Jenkins on a slave EC2 instance that starts and stops with the build

Ideally, we'd like to run load tests on an EC2 Jenkins slave that starts and stops with our build.
Are there any tools out there (without writing our own plugins) that currently solve this?
I've come across this, but it seems to only be triggered based on the load of Jenkins in general, and not tied to a build.
This configuration is environment specific, and not project specific, so I would prefer to keep this maintained within Jenkins instead of within Maven and the project itself. Although, I'm open to suggestions in that realm.
You can check out WebLOAD Jenkins plugin, it executes RadView's WebLOAD load testing tool, triggered by Jenkins. WebLOAD itself can launch EC2 cloud machines as needed, if that's what you need.

IntelliJ, Maven, JRebel (?), Tomcat and Continuous Integration. How To?

I am new in Java and Continuous Integration. I want to setup a development environment using IntelliJ, Maven, GIT and JRebel (this was strongly recommended by a friend of mine). Tomcat Server is on AWS, not on my local Mac OS X machine. Is it possible to use GIT / JRebel and 'update' the remote project on the fly (after saving the files?). Which modules should I install on my Mac and which on Tomcat? Do I need Jenkins as well?
With JRebel Remoting, it is possible to push the changes to the remote applications, without having to configure any extra ports even. This is applicable if you would like to code something in the IDE, and then just push the changes to the remote application. But if you'd like to run the full test suite, then it is better to do via CI and then you will have quite different process - you will have to wait a bit longer until your changes become visible in the running app.

Automate Maven Scripts

I have a series of Maven Scripts which are to be run in Linux Platform for doing Reversion and Lableing for my Project. I would like to know what Building Tools i can use to automate the Maven Scripts in the Linux Platform?
Also say suppose I have got some error while doing the Reversioning / Lableing of the code. How can the Automate tools Handle these scenarios.
Please let me know of the effective tools and I would certainly reply back whether those do help me out or not!
I would suggest leveraging a "job" coordinator such as Jenkins or Cruise Control to manage any and all of our automation. Maven is natively supported and understood by these tools. An agent will reside on your server, and do the bidding of your coordinator.
Jenkins is a good solution to automate maven build:
easy to install
easy integration with maven
allow you to automate simple task after build failure/success like sending email
many plugins including this one that allow you to do more complex task after a build failure (or build success)
Any one of this
Jenkins
Hudson
Atlassian bamboo
TeamCity
After using LuntBuild, Jenkins and teamcity I can say without a doubt that TeamCity is by far the superior choice.
I think it's free for a small configuration (3 agents, and up to 10 build configurations).
It very easy to install and configure, compatible with most source control systems.

Resources