## page was renamed from ServerTeam/NattyIdeaPool/HudsonSpec
##(see the SpecSpec for an explanation)

 * '''Launchpad Entry''': UbuntuSpec:packageselection-server-n-hudson
 * '''Created''': JamesPage
 * '''Contributors''': 
 * '''Packages affected''': n/a

== Summary ==

This specification details the inclusion of the Hudson continuous integration stack in the Natty cycle.  Questions to answer:

 * What approach do we take to packaging and distributing Hudson (see build from source challenges)?
 * Which other Ubuntu developments might take advantage of this packaging (for example ubuntu-server-iso-testing)?
 * How can we manage plugin download and installation outside of Ubuntu packaging?

== Release Note ==

Ubuntu 11.04 comes with support for Hudson: hudson is available through the Ubuntu archives. 

== Rationale ==

Hudson provides a flexible, scalable continuous integration tool-set; As the open-source tool of choice for Java developers, Ubuntu Server needs to support this stack.

Hudson also has use cases outside of Java development (including Python development) through the large number of plugins available for the tool-set.

== User stories ==

As a Java developer, I want to be able to deploy Hudson quickly and easily; I use the packaging available in 11.04 and everything is easily installed.

As a System Adminstrator, I want to be able to deploy a Hudson cluster quickly and easily; I use the hudson and hudson-slave packaging available in 11.04 and everything is easily installed and configured.

== Assumptions ==

None

== Design ==

=== General Approach ===

Hudson can be deployed in the majority of servlet containers; providing options for tomcat and jetty through Ubuntu would make sense as they are already in the archive.  Hudson can also be executed 'standalone' using the embedded winstone servlet container.

We should also aim to ease the deployment and management of slave nodes.

Another important aspect of deploying Hudson is to ensure that each of the nodes executing build has the same set of deployed build tools; this potentially includes ant and maven.

=== Package Structure ===

==== hudson-common ====

Common parent package which contains the hudson.war file (potentially from the upstream binary distribution) and associated configuration files.  This differs from the Hudson Labs debian package as it will '''not''' add users, install startup scripts etc...

==== hudson-slave ====

Slave agent package which contains the slave.jar file (potentially from the upstream binary distribution), associated configuration files and init scripts.

This could be a really lightweight package as the slave.jar file can be sourced from the hudson master server; this could also help with upgrades as the init scripts could automatically download the latest version of the slave.jar as part of the startup process.

Installation/configuration process could then just identify which master server the slave should be talking to.

More documentation here >http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds on the various options.

==== hudson-tomcat ====

Wrapper package which installs both tomcat6 and hudson on the same system.

==== hudson-jetty ====

Wrapper package which installs both jetty and hudson on the same system.

=== Packaging Complexity ===

 * The Hudson web application relies on 90 dependent libraries at runtime and a large number during the maven build process(see [[attachment:hudson-1.381-dependencies-xref.txt]]); about ~100 potentially intersect with versions currently available in the Ubuntu Archive and ~50 are not currently packaged.
 * The Hudson project appears to have localised versions of some libraries (see versions with -hudson or -kohsuke postfix) which could make building from source problematic. 
 * Plugins are downloaded directly from http://hudson-ci.org/download/plugins/ and are managed by individual maintainers who have commit access to Hudson. 
 * Releases are also very frequent

== Implementation ==

See work items on appselection-server-n-hudson whiteboard. 

=== UI Changes ===

None

=== Code Changes ===

No code changes are required as this is a new stack for the platform.

=== Migration ===

None

== Test/Demo Plan ==

TBC

== Unresolved issues ==

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

== BoF agenda and discussion ==

=== UDS discussion notes ===

----
CategorySpec