HudsonInNetBeans

Revision as of 17:10, 14 June 2012 by Jglick (Talk | contribs)

Contents

Features

General setup and view

See Hudson Builders in the Services tab.

Connect to one or more Hudson servers by giving the URL and a display label. (Jenkins will also work though it is not tested or formally supported.)

Set a refresh interval in minutes. If zero, after a restart the server will initially be left unconnected - you can manually "synchronize" when you want to. You can always manually synchronized rather than waiting. If synchronizing hangs (server not responding, ...) the task can be canceled and resynchronization should be suppressed for the rest of the IDE session.

All jobs in the default view are shown; you can select an alternate view if you like. Each job shows its current workspace, and a list of builds (shown with their status color - stable, unstable, failed, aborted - plus a badge if currently running). Completed builds show a list of artifacts; builds of native Maven jobs show a list of modules, each of which may have its own artifacts.

Most nodes permit you to open the corresponding URL in an external web browser for more information and control. Job nodes let you open the config.xml (Hudson's persisted job configuration file) in the IDE's editor as a convenience, though currently this is read-only.

Jobs may be started manually from the context menu.

Authentication

You may use the Log In... action to supply credentials to a controlled server. For publicly browsable servers it is unnecessary - if and when you take some action which requires a login, such as creating or starting a job, you will be prompted automatically. Less commonly a server may be configured to simply hide some jobs when not logged in, in which case you need to do so explicitly. Credentials are remembered using the secure keyring, though currently you are not logged in automatically after restarting the IDE.

Supported authentication types (as of 7.2):

  • username/password in Hudson's own database (the default mode)
  • servlet container authentication
  • API token (currently Jenkins only)

Notifications

If a build on a registered server is not stable, a popup notification appears in the IDE. If it failed, you are offered a chance to see the log (#Build log browsing). If it succeeded but was unstable, you are offered a chance to see the test failures (#Failed test display).

Notifications are displayed only for jobs that are "watched". All jobs are initially watched on a manually registered server; for a transient server registered according to a project association which specifies a job (#Project/job associations), just that job is watched. A notification will offer to stop watching a job in case it is irrelevant to you. You can always turn watching on or off directly in the Properties of the job (should probably be made into a checkbox menu item).

Once you have seen a notification for a particular failed/unstable build, it will not be displayed again (even after IDE restart), but if a new build fails a fresh notification will appear (only one at a time for a given job).

Changelogs and diffs

A context menu item on a build lets you see its changelog, currently displayed in a simple text format in the Output Window. Subversion, Git, and Mercurial are currently supported.

Per-file changes are hyperlinked where possible, displaying the change in the IDE's diff viewer (typically with syntax coloring); this works only for SCM setups where the versioned file contents can be retrieved in a straightforward way over HTTP.

Currently the changeset ID or revision number is not displayed, and there is no hyperlink to an online changeset URL, but these things would be possible where supported by the corresponding Hudson SCM plugin.

Workspace/artifact browsing

Assuming a job has a workspace, it is displayed in a tree view beneath the job node. (Only the most recently used workspace is shown, for jobs running on multiple nodes with independent workspaces.)

Subdirectories and files can be browsed just like in the Files or Favorites tabs, and files can even be opened (read-only) in the IDE's editor with syntax coloring. When the server is resynchronized, changes to the workspace should be reflected in the IDE's view. ZIP/JAR files can be expanded to see entries, you can copy and paste files into a project source tree, etc.

Builds which created artifacts also show these using the same kind of viewer, so you can easily verify that file contents are correct, copy a JAR into Favorites, etc.

All such file operations run directly against the remote server, so they can be slow if the server is heavily loaded, but no more is transferred over the network than necessary.

Failed test display

XXX describe current state

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

Version skew is a potential problem.

Build log browsing

XXX describe current state

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.

Quick search

XXX describe current state

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.

Project/job associations

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.

Servers registered as a result of a project being opened are marked as "transient" (a label is shown in the UI) and are unregistered when the project is closed. You may choose to persist the server configuration so it will be shown even after closing the project.

You can also manually associate a job with a specific project, useful if you set up the job manually in the web UI.

Static analysis result display

XXX describe current state

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?

Plugin development

XXX describe current state

Historical

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

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

Original HudsonInNetBeansUI spec.

ContinuousIntegrationHOWTO is obsolete (relies on Kenai).

Implementation

In hudson* modules.

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

How to develop

Source setup

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

Commit to core-main; NB-Core-Build will run tests for those modules which have any. Set up hudson*/* notifications in .hgmail.

Running in devel mode

Now run 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). Subversion and Git plugins should be installed by default.

For testing projects using Ant or Maven, you will need to configure at least one installation of the relevant tool: go to Manage Hudson, and ask to automatically install the latest version from Apache (beware that this list is sometimes out of date or even broken).

Tests

Various pieces of code have unit tests, which should all be stable. There are no functional tests currently that would confirm that interaction with a particular version of Hudson using the remote API actually works, though this would be possible.

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

Remote API

XXX how it works in Hudson/Stapler, how /xml/api is used by NB (XPath & tree=)

Internal APIs

XXX

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