HudsonInNetBeans

(Difference between revisions)
(Competition)
(Features)
Line 1: Line 1:
=Features=
=Features=
-
 
-
Also see: [[NewAndNoteworthyMilestone3NB67#HudsonIntegration]]
 
-
 
-
[[ContinuousIntegrationHOWTO]] is obsolete (relies on Kenai).
 
==Automatic setup of CI==
==Automatic setup of CI==
-
Should be easy to take an IDE project, or project tree, or kenai.com workspace,
+
Can take an IDE project, or project tree,
and set up a new CI job for it.
and set up a new CI job for it.
 +
(Team > Create Build Job...)
-
For a NB-generated Ant project, this means a freeform job
+
For an IDE-managed Ant project (e.g. j2seproject), this means a "freeform" job
-
invoking <tt>build.xml</tt> with the <tt>test</tt> target,
+
(i.e. job's config.xml lists every build step and file location explicitly)
-
collecting <tt>dist/*.jar</tt> and test result artifacts.
+
invoking <tt>build.xml</tt> with targets like jar/test/javadoc,
 +
collecting <tt>dist/*.jar</tt>, test result artifacts, and/or Javadoc.
-
For a freeform or automatic Ant project, this may not be possible without user intervention.
+
For a freeform or automatic Ant project, this is likely impossible - the user would have to set everything up themselves anyway.
For a Maven project (possibly consisting of multiple modules),
For a Maven project (possibly consisting of multiple modules),
-
this would be best handled by using Hudson's native Maven 2+ support.
+
this is handled by using Hudson's native Maven 2+ support.
-
The IDE should also populate the CI field in <tt>pom.xml</tt>.
+
(''Note:'' Hudson after the Jenkins split supposedly deprecates this job type,
 +
but it still seems to work fine, and is much more convenient for the IDE's purposes.)
 +
 
 +
PHP projects are also supported, using a semistandard PHP setup system for Hudson.
 +
 
 +
===SCM handling===
 +
 
 +
The job can only be set up if the IDE can determine the location of the version control repository used by the job, based on metadata in your current project's checkout. The contents of the local project tree are ignored thereafter - to trigger new builds, you need to commit (and, if applicable, push) changes. The job config will include a simple default SCM configuration, polling for changes at some interval.
 +
 
 +
Currently Subversion (pre-1.7), Git, and Mercurial are supported for this purpose. For the DVCS, it is supported to start from a project repository with no remote server location, if you are running the Hudson server on localhost (i.e. solo development or just giving a demo); then the job config will use a file-protocol URL, and just committing locally will trigger builds.
 +
 
 +
===Linking back to the server===
 +
 
 +
When a Maven project is set up,
 +
the IDE will also populate the standard ciManagement field in <tt>pom.xml</tt>,
 +
so that if the project is opened again by a NetBeans user this Hudson server will automatically be registered (with this job being "watched"). The IDE will also recognize ciManagement (of type <tt>hudson</tt> or <tt>jenkins</tt>) defined manually in any POM, which well-maintained projects may already have.
 +
 
 +
For other project types (Ant/PHP), the server link is added to project metadata too.
==Monitoring and control==
==Monitoring and control==
Line 59: Line 74:
* How can the user keep the task list manageable if there are 7000 FindBugs warnings?
* How can the user keep the task list manageable if there are 7000 FindBugs warnings?
* How should analysis warnings be rejected? Annotations?
* How should analysis warnings be rejected? Annotations?
 +
 +
==Historical==
 +
 +
Originally a third-party plugin by Michal Mocnak (mmocnak).
 +
 +
Feature set as of original integration into NB official distro: [[NewAndNoteworthyMilestone3NB67#HudsonIntegration]]
 +
 +
[[ContinuousIntegrationHOWTO]] is obsolete (relies on Kenai).
=Implementation=
=Implementation=

Revision as of 14:32, 14 June 2012

Contents

Features

Automatic setup of CI

Can take an IDE project, or project tree, and set up a new CI job for it. (Team > Create Build Job...)

For an IDE-managed Ant project (e.g. j2seproject), this means a "freeform" job (i.e. job's config.xml lists every build step and file location explicitly) invoking build.xml with targets like jar/test/javadoc, collecting dist/*.jar, test result artifacts, and/or Javadoc.

For a freeform or automatic Ant project, this is likely impossible - the user would have to set everything up themselves anyway.

For a Maven project (possibly consisting of multiple modules), this is handled by using Hudson's native Maven 2+ support. (Note: Hudson after the Jenkins split supposedly deprecates this job type, but it still seems to work fine, and is much more convenient for the IDE's purposes.)

PHP projects are also supported, using a semistandard PHP setup system for Hudson.

SCM handling

The job can only be set up if the IDE can determine the location of the version control repository used by the job, based on metadata in your current project's checkout. The contents of the local project tree are ignored thereafter - to trigger new builds, you need to commit (and, if applicable, push) changes. The job config will include a simple default SCM configuration, polling for changes at some interval.

Currently Subversion (pre-1.7), Git, and Mercurial are supported for this purpose. For the DVCS, it is supported to start from a project repository with no remote server location, if you are running the Hudson server on localhost (i.e. solo development or just giving a demo); then the job config will use a file-protocol URL, and just committing locally will trigger builds.

Linking back to the server

When a Maven project is set up, the IDE will also populate the standard ciManagement field in pom.xml, so that if the project is opened again by a NetBeans user this Hudson server will automatically be registered (with this job being "watched"). The IDE will also recognize ciManagement (of type hudson or jenkins) defined manually in any POM, which well-maintained projects may already have.

For other project types (Ant/PHP), the server link is added to project metadata too.

Monitoring and control

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.

Changelog and source review

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).

Hyperlinks for test failures, warnings, ...

Stack trace hyperlinking for e.g. unit test failures in a completed build.

Version skew is a potential problem.

Build log browsing

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.

Static analysis result display

TBD. Open questions:

  • Should we use the task list for this?
  • How to deal with version skew?
  • How can the user keep the task list manageable if there are 7000 FindBugs warnings?
  • How should analysis warnings be rejected? Annotations?

Historical

Originally a third-party plugin by Michal Mocnak (mmocnak).

Feature set as of original integration into NB official distro: NewAndNoteworthyMilestone3NB67#HudsonIntegration

ContinuousIntegrationHOWTO is obsolete (relies on Kenai).

Implementation

In hudson* modules.

Use the connecteddeveloper component in Bugzilla. Create issue; Open issues

Original HudsonInNetBeansUI spec is of historical interest.

How to develop

Build the IDE with at least

cluster.config=basic

Now create a project group containing at least these NB modules:

hudson
hudson.ant
hudson.git
hudson.maven
hudson.mercurial
hudson.subversion
hudson.tasklist

and optionally also:

hudson.php
java.helpset
nbbuild

and Debug Project on Hudson. This debug target is set up to enable verbose console logging in Hudson-related modules. (It is also suitable for setting as "main project" since its debug target rebuilds all the submodules too.)

Originally "Try Hudson on Localhost" was the easiest way to get started, though this is currently disabled (#214210), so just download the latest WAR and java -jar it (will open at http://localhost:8080/ by default). Install the Mercurial plugin from the update center if you want to test this integration (though the version available on the Hudson UC is quite old; the Jenkins UC has the latest).

Working with non-IDE sources

Useful to have checkouts of:

git://git.eclipse.org/gitroot/hudson/org.eclipse.hudson.core.git (3.x)
git://github.com/hudson/hudson.git (2.x)
git://github.com/hudson-plugins/git-plugin.git
git://github.com/jenkinsci/mercurial-plugin.git
git://github.com/jenkinsci/multiple-scms-plugin.git
git://github.com/jenkinsci/analysis-core-plugin.git
git://github.com/jenkinsci/findbugs-plugin.git (etc.)
git://github.com/stapler/stapler.git
git://github.com/jenkinsci/jenkins.git
https://bitbucket.org/jlahoda/jackpot30 (subdir hudson.indexerinstaller; experimental)

To build and run Hudson from sources, just open the top aggregator project and Build Project (probably want to suppress tests for non-test-related executions in Maven settings). Then open the hudson-war module and Run Project, which should automatically call hudson-dev:run. Theoretically you can make incremental changes to Java and Jetty will automatically restart, though this seems to break things. Can edit Jelly XML (HTML templates) and the results should be live upon save.

To build and run plugins from sources, just open them and Run Project. This will run the plugin using Jetty against its configured baseline Hudson (or Jenkins) version. Or, just Build Project to create a *.hpi, and then install this manually into a running Hudson instance (see Manage Plugins / Advanced).

Competition

Other Hudson IDE plugins:

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo