Skip to main content
System StatusContact Support Agility Community

VersionOne Integration for Hudson

This feature is available in all editions.




The VersionOne Integration for Hudson creates a record of builds in VersionOne, so development teams can associate stories and defects to a particular build. This visibility is useful when identifying problem builds or generating release notes.

Once the plugin has been installed, team members include a VersionOne identifier, such as “S-01454” or "TK-01234", in the comments of their SCM commit. Every time a build executes the publisher creates a BuildRun asset in VersionOne with details of the build. The VersionOne BuildRun is visible on the Relationship tab on the Story/Defect Details page.

Using this integration you can better answer the following questions:

  • For Defects:

    • Which build the defect was reported against?

    • Which build contained the fix for the defect?

    • Which builds contain work for the defect?

  • For Stories (Backlog Item):

    • Which builds contain work for the story?

    • Which build contained the completed story?

  • For Build Runs:

    • Which defects were fixed?

    • Which stories were completed?

    • Which defects were introduced?

    • When work for a story or defect was included?

    • Which Change-sets were included?

  • For a range of Build Runs:

    • Which stories were completed?

    • Which defects were fixed?

    • Which defects were introduced?


Application files for the current and previous versions of this integration can be found in the AppCatalog.

Source Code

Source code for this integration can be found in GitHub.

Sequence Diagram

The following sequence diagram illustrates the VersionOne Integration for Hudson behavior.

Hudson Sequence Diagram

System Requirements

VersionOne Lifecycle:

  • 8.1 or above, including Team Edition

Integration Server:

  • Operating Systems: Windows 2000, 2003

Continuous Integration Server:

  • Tested with Hudson version 1.336 - 2.1

Supported Source Code Management:

  • Subversion - 1.17 or better

  • Perforce - 1.1.5 or better

  • Git - 1.3.1 or better


These instructions presume that Hudson is already installed, configured, and working properly.

  1. Ensure Connectivity
    Verify that you can connect to your VersionOne instance from the machine hosting Hudson

  2. Extract Files
    Download VersionOne plugin from the link above and extract it into a folder of your choice. This can be a temporary location since we will copy some of these files during configuration.

  3. Configure

    1. Configure Lifecycle

    2. Configure Hudson

  4. Verify the installation

  5. Once configuration is complete, follow the steps below to verify that the build integration is working

    1. Navigate to your Hudson instance.

    2. Force a build on the project you configured.

    3. Wait for build to complete, and then log into your VersionOne instance.

    4. Select the VersionOne project in the Project Navigator.

    5. On the main menu, select Reports, and then click on the Build Run Quicklist report.


Step 1. Configure VersionOne

  1. Log into VersionOne as an administrator.

  2. From the Admin menu, select Configuration, and then click on the System tab.

  3. Select the Enable Build Integration checkbox, and then click the Save button.

  4. To build a new project, go back to the Admin, select Projects, and the select Build Project.

  5. Click the Add button, and then enter the following:

    • Name. This is how the build project displays to VersionOne users.

    • Reference. This is how the build project displays in Hudson.

    • (Optional) Description. Enter a more details about the build project.

  6. Click Save.

  7. Click on the Projects tab.

  8. On the row for the project you want associated with the build project, select Edit from the Add Child Project drop-down menu.

  9. Scroll to the Build Projects field, and then select a build project from the drop-down list.

  10. Click Save to accept the changes, and then log out of VersionOne.

Step 2. Configure Hudson

  1. Log into Hudson as an administrator.

  2. On the Hudson Dashboard, Click Manage Hudson.

  3. Click Manage Plugins, and then click Advanced.

  4. Under Upload Plugin, browse to your download location, select the versionone.hpi file, and then click Upload.HudsonUploadPlugin.png

  5. Restart your Hudson instance to load the new plugin.

  6. On the Hudson Dashboard, Click Manage Hudson.

  7. Click Configure System. A new VersionOne section displays at the end of this page.

  8. Provide your VersionOne connection parameters.

  9. If you connect to VersionOne through a proxy, select the Use proxy server checkbox and provide additional proxy parameters.

    We recommend that you do not change the Reference Field or Comment RegEx fields. The Reference Field is the system name of the attribute to search when matching the ID in change comments with workitems in VersionOne. The Comment RegEx is used to extract workitem identifiers from the change comments.

  10. Test the connection, and then save the settings.

  11. Choose the Job you want to publish to VersionOne. Remember that this job name must be configured in VersionOne.

  12. Click Configure to configure the workspace.

  13. In the Post-build Actions section, click the VersionOne Notifier check box, and then click Save.

Technical Details

Adding Support for Another Source Code Management System

To add support for new VCS, the following actions are required:

  1. Add plugin reference to pom.xml, make sure that this dependency could be successfully resolved.

  2. Add a class wrapping native changeset type. SvnModification or PerforceModification are good examples on how to do it.
    New class must inherit VcsModification interface and provide parameterless public constructor.

  3. Modify VcsModificationWrapperFactory class to support new changeset type.
    It is required to add line similar to classNameMappings.put("hudson.plugins.perforce.PerforceChangeLogEntry","com.versionone.hudson.PerforceModification"). String literals are mappings of native changeset log entry classes to our custom wrappers in format supported by Java Reflection, so that instances and class objects could be successfully created. Changesets will be processed as soon as user installs the corresponding plugin and restarts Hudson server. In fact, our plugin won’t start without its dependencies.