In hudson* modules.
Development: cdev repo and its builder pushes to regular builds.
Use the hudson component in Issuezilla. Create issue; Open issues; Related open issues
HudsonInNetBeansUI spec is in progress.
For easiest testing, create nbbuild/user.build.properties with:
cluster.config=basic tryme.args=-J-Dnetbeans.full.hack=true -J-Dorg.netbeans.modules.hudson.level=FINERand start your own private Hudson instance.
Also see: NewAndNoteworthyMilestone3NB67#HudsonIntegration
See also a simple end-to-end HOWTO document.
Should be easy to take an IDE project, or project tree, or kenai.com workspace, and set up a new CI job for it.
For a NB-generated Ant project, this means a freeform job invoking build.xml with the test target, collecting dist/*.jar and test result artifacts.
For a freeform or automatic Ant project, this may not be possible without user intervention.
For a Maven project (possibly consisting of multiple modules), this would be best handled by using Hudson's native Maven 2 support. The IDE should also populate the CI field in pom.xml.
Setup of Rails projects is TBD.
Basic monitoring and control from the IDE, along the lines of what the current module does but more polished: see running builds, get unobtrusive notifications when a build fails (especially if you are listed in the changelog!), maybe start or cancel builds, and of course jump to the main Hudson interface in a web browser for anything not better supported inside the IDE.
Ability to review build's changelog using IDE's diff viewer; maybe to switch workspace to VCS snapshot represented by build. Ability to browse job's workspace remotely using a tree view in the IDE (and open files R/O).
Stack trace hyperlinking for e.g. unit test failures in a completed build.
Version skew is a potential problem.
Display of build log in IDE's Output Window, with hyperlinks to remote workspace (or local workspace equivalents) for any files mentioned by name.
Version skew is a potential problem.
TBD. Open questions:
Other Hudson IDE plugins: