Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

There are three methods that are relevant when Hudson is determining if there has been a change in the SCM:

  • public boolean supportsPolling()
  • public boolean requiresWorkspaceForPolling()
  • before Hudson 1.346: public boolean pollChanges(AbstractProject, Launcher, FilePath, TaskListener)
  • after Hudson 1.346: public PollingResult compareRemoteRevisionWith(AbstractProject, Launcher, FilePath, TaskListener, SCMRevisionState)
  • after Hudson 1.346: public SCMRevisionState calcRevisionsFromBuild(AbstractBuild, Launcher, TaskListener)


This methods determines if the SCM plugin can be used for polling. Default method returns true.


This method should return true if the SCM requires a workspace for polling. What to return depends on the SCM that the plugin is using. For instance the ClearCase plugin requires that a build has been performed before it can poll for changes, whereas Team Foundation Server does not require a workspace to poll for changes. Default method returns true.

pollChanges (<1.346)

This method does the actual polling and should return true or false if there are any changes in the repository. The polling should be as quick as possible and does not need to output any other result than a boolean.

To determine the date to get changes from, use the AbstractProject.getLastBuild().getTimestamp() to get a Calendar object.

compareRemoteRevisionWith (>=1.346)

This method does the actual polling and returns a PollingResult. The change attribute of the PollingResult the significance of the changes deteced by this poll.

Value of 'change' (enum)



The were no changes since the last built.


There were changes since last build, but they are not significant enough to warrant a new build, e.g. because some SCMs allow certain commits to be marked as excluded.


There are changes between states that warrant a new build.


The state as of baseline is so different from the current state that they are incomparable, for example, the workspace and the remote repository point to two unrelated repositories because the configuration has changed. This forces Jenkins to schedule a build right away. PollingResult.BUILD_NOW is basically an alias to {{PollingResult.}}INCOMPARABLE

calcRevisionsFromBuild (>=1.346)

Calculate the state of the workspace of the given build. The returned object is then fed into compareRemoteRevisionWith as the baseline SCMRevisionState to determine if the build is necessary, and is added to the build as an Action for later retrieval.

  • No labels


  1. Unknown User (hagzag)

    Currently we are using CroiseContorl and Build_Number is driven / set by SCM Change-list.

    Looking for a feature which should in my opinion be provided by Hudson SCM core service and that is to set the Build_Number according to the SCM Changlist / Revision number.

    I am currently using perforce and looking for a "Build Number according to Chang-list" feature - if there is an intention on adding this I would be happy to know.

    In additinon I see NextBuildNumber is an int and cannot have any Alapnumeric characters any good reason for that ? I would like to have "R" appended to the build number to builds I have released and "Q" for QA builds - my build wrapper today does all the above automatically before build starts in cruise so build context is kept with the specific change list + Release / QA tag.

    Thank You


  2. Unknown User (rmyung)

    The description in this page made me think that during a polling operations Jenkins would call calcRevisionsFromBuild, then pass the results to compareRemoteRevisionWith.

    However, I've set breakpoints at compareRemoteRevisionWith and calcRevisionsFromBuild and it looks like only compareRemoteRevisionWith is called.  When is calcRevisionsFromBuild called?