IntenseDebate - jdcasey

14 years ago @ Sonatype Blog - The Hudson Build Farm ... · 0 replies · +1 points

@T_M:

You can think of an executor as a build "slot" on a particular VM. These determine how many simultaneous jobs can run on that slave, and allows you to tune how much pressure Hudson will put on your slave VM. If you have one slave with two CPU cores, and another with a single core, you might allocate 3 executors to the first one, and only 2 to the second.

Why 3 and 2, instead of 2 and 1? In my experience, some builds can get "wedged" waiting for SCM to respond, waiting for network timeouts in your repository access (the network can always fail), etc. So, having # cores +1 executors gives you the ability to keep building even if one of your jobs gets stuck.

14 years ago @ Sonatype Blog - Create a Customized Bu... · 0 replies · +1 points

That's true; a basic lifecycle reference is available on the Maven website:

http://maven.apache.org/guides/introduction/intro...

However, I chose to reference the book chapters in this post since (I hope) it gives a more user-friendly introduction. It also gives the reader a natural jumping-off point from which to learn more about the rest of Maven, since there's a pretty complete table of contents available.

As for documentation on writing custom lifecycle mappings, artifact handlers, and the workarounds necessary to get it all working, I'm unaware of any pre-existing documentation out in the wild...

14 years ago @ Sonatype Blog - Maven 2.2.0 Released! · 0 replies · +1 points

No, unfortunately this didn't make much of a performance improvement, though we have seen that authentication handling (either preemptive or per-request) is much worse with the way httpclient is used in the non-lightweight http wagon.

For the 2.2.1 release we're planning, we've reverted to using the Sun http implementation to give us the chance to sort out the problems with the httpclient-driven wagon. However, 2.2.1 will also give users more flexibility to specify which wagon implementation they want to use for a particular protocol, so if we get a new version of the httpclient-driven wagon released users should be able to make immediate use of it.

14 years ago @ Sonatype Blog - Maven 2.2.0 Released! · 0 replies · +1 points

It should be available by now. There were some hiccups with the release process, and I neglected to copy the binaries over from the Maven repository into the dist directory where ASF binaries are officially housed.

14 years ago @ Sonatype Blog - Maven 2.2.0 Released! · 0 replies · +1 points

Unfortunately, we haven't updated that yet. The general feeling was to avoid causing nasty (or pleasant for some, I guess) surprises for users. The project itself isn't completely transitioned over to Java 5 syntax, so I suspect we'll get deeper into this as time goes on.

15 years ago @ Sonatype Blog - The Hudson Build Farm ... · 0 replies · +1 points

Yeah, pinning down the java path for the hudson slave is an important step. Actually, so is the process of standardizing all the default tool paths for a slave, just in case a job definition doesn't specify *which* Maven or Java to use...which is why we actually decided to write a few launch scripts for the slave.jar. Basically, we have a *nix start.sh BASH script, a Windows start.bat batch file, and another BASH script - start-solaris.sh - that we use to account for some of the pathing differences between *nix and Solaris.

This allows us to standardize the runtime environment for all slave instances without being forced to manage environment variables in their default locations (.bashrc on *nix usually, or the system registry on Windows).

15 years ago @ Sonatype Blog - The Hudson Build Farm ... · 1 reply · +1 points

Actually, Xvnc/Xvfb/etc. (for tests and builds that require graphical environments) are still on our TODO list for the build farm. Based on a couple weak attempts to get some things to build in this sort of a scenario, it seems that getting graphical builds working on a mixed environment of windows and *nix is going to be interesting, to say the least.

If you have any wisdom to offer on this point, I'd be really interested to hear.

15 years ago @ Sonatype Blog - The Hudson Build Farm ... · 0 replies · +1 points

When you start up VMWare Infrastructure Client and go to the Summary tab on the startup window (or, click on the root tree-node at left, and then go to the Summary tab at right), you should see an overall usage widget for CPU and memory...also, you can click on the Performance tab in the same tree node and see graphs of different resource utilizations.

The graph is probably the most useful, since you can see a little history there (it tends to be a bit difficult to catch the VMWare server at a moment of high utilization, since it will respond to the infra client sluggishly). The spikes on that graph are what you're watching for. Scanning our graph right now, I can see that we're peaking at around 80% of resources, and only staying there momentarily. Responsiveness within the farm during those times is probably a little sluggish, but as long as you're not hanging out in the high-utilization zone for too long, things should keep rolling along pretty well.

Hope that helps.

15 years ago @ Sonatype Blog - The Hudson Build Farm ... · 0 replies · +1 points

I think instead of editing this post, I'm going to work on a visual tour of the build farm setup. That way, I can cover things that I've talked about in several of these posts, without duplication.

15 years ago @ Sonatype Blog - The Hudson Build Farm ... · 0 replies · +1 points

Thanks Matthew! I'm bookmarking this on my delicious account now, and I'll be using this in the future for sure.

IntenseDebate Comment System

Description

Connect with jdcasey

People I'm following

jdcasey