HudsonSpec
3499
Comment:
|
4340
page was renamed from ServerTeam/NattyIdeaPool/HudsonSpec
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## page was renamed from ServerTeam/NattyIdeaPool/HudsonSpec | |
Line 3: | Line 4: |
* '''Launchpad Entry''': UbuntuSpec:foo * '''Created''': 24th September 2010 * '''Contributors''': JamesPage |
* '''Launchpad Entry''': UbuntuSpec:appselection-server-n-hudson * '''Created''': JamesPage * '''Contributors''': |
Line 10: | Line 11: |
This specification details the inclusion of the Hudson continuous integration stack in the Natty cycle. | 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? |
Line 20: | Line 25: |
Hudson also has use cases outside of Java development through the large number of plugins available for the tool-set. | Hudson also has use cases outside of Java development (including Python development) through the large number of plugins available for the tool-set. |
Line 66: | Line 71: |
=== Packaging Complexity === * The Hudson build process is Maven based and relies on 88 dependent libraries; the majority of which do not intersect with versions currently available in the Ubuntu Archive. * 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 |
|
Line 68: | Line 79: |
See work items on server-natty-hudson whiteboard. | See work items on appselection-server-n-hudson whiteboard. |
Launchpad Entry: appselection-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 build process is Maven based and relies on 88 dependent libraries; the majority of which do not intersect with versions currently available in the Ubuntu Archive.
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
ServerTeam/Specs/HudsonSpec (last edited 2010-10-28 13:09:47 by host194)