hudson.tasks
Class Fingerprinter
java.lang.Object
hudson.tasks.BuildStepCompatibilityLayer
hudson.tasks.Publisher
hudson.tasks.Recorder
hudson.tasks.Fingerprinter
- All Implemented Interfaces:
- ExtensionPoint, Describable<Publisher>, BuildStep, Serializable, DependencyDeclarer
public class Fingerprinter
- extends Recorder
- implements Serializable, DependencyDeclarer
Records fingerprints of the specified files.
- Author:
- Kohsuke Kawaguchi
- See Also:
- Serialized Form
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
enableFingerprintsInDependencyGraph
public static boolean enableFingerprintsInDependencyGraph
Fingerprinter
@DataBoundConstructor
public Fingerprinter(String targets,
boolean recordBuildArtifacts)
getTargets
public String getTargets()
getRecordBuildArtifacts
public boolean getRecordBuildArtifacts()
perform
public boolean perform(AbstractBuild<?,?> build,
Launcher launcher,
BuildListener listener)
throws InterruptedException
- Description copied from interface:
BuildStep
- Runs the step over the given build and reports the progress to the listener.
A plugin can contribute the action object to Actionable.getActions()
so that a 'report' becomes a part of the persisted data of Build
.
This is how JUnit plugin attaches the test report to a build page, for example.
- Specified by:
perform
in interface BuildStep
- Overrides:
perform
in class BuildStepCompatibilityLayer
- Returns:
- true if the build can continue, false if there was an error
and the build needs to be aborted.
Using the return value to indicate success/failure should
be considered deprecated, and implementations are encouraged
to throw AbortException
to indicate a failure.
- Throws:
InterruptedException
- If the build is interrupted by the user (in an attempt to abort the build.)
Normally the BuildStep
implementations may simply forward the exception
it got from its lower-level functions.
getRequiredMonitorService
public BuildStepMonitor getRequiredMonitorService()
- Description copied from interface:
BuildStep
- Declares the scope of the synchronization monitor this
BuildStep
expects from outside.
This method is introduced for preserving compatibility with plugins written for earlier versions of Hudson,
which never run multiple builds of the same job in parallel. Such plugins often assume that the outcome
of the previous build is completely available, which is no longer true when we do concurrent builds.
To minimize the necessary code change for such plugins, BuildStep
implementations can request
Hudson to externally perform synchronization before executing them. This behavior is as follows:
BuildStepMonitor.BUILD
-
This
BuildStep
is only executed after the previous build is fully
completed (thus fully restoring the earlier semantics of one build at a time.)
BuildStepMonitor.STEP
-
This
BuildStep
is only executed after the same step in the previous build is completed.
For build steps that use a weaker assumption and only rely on the output from the same build step of
the early builds, this improves the concurrency.
BuildStepMonitor.NONE
-
No external synchronization is performed on this build step. This is the most efficient, and thus
the recommended value for newer plugins. Wherever necessary, you can directly use
CheckPoint
s
to perform necessary synchronizations.
Migrating Older Implementation
If you are migrating BuildStep
implementations written for earlier versions of Hudson,
here's what you can do:
-
Just return
BuildStepMonitor.BUILD
to demand the backward compatible behavior from Hudson,
and make no other changes to the code. This will prevent users from reaping the benefits of concurrent
builds, but at least your plugin will work correctly, and therefore this is a good easy first step.
-
If your build step doesn't use anything from a previous build (for example, if you don't even call
Run.getPreviousBuild()
), then you can return BuildStepMonitor.NONE
without making further
code changes and you are done with migration.
-
If your build step only depends on
Action
s that you added in the previous build by yourself,
then you only need BuildStepMonitor.STEP
scope synchronization. Return it from this method
,and you are done with migration without any further code changes.
-
If your build step makes more complex assumptions, return
BuildStepMonitor.NONE
and use
CheckPoint
s directly in your code. The general idea is to call CheckPoint.block()
before
you try to access the state from the previous build.
Note to caller
For plugins written against earlier versions of Hudson, calling this method results in
AbstractMethodError
.
- Specified by:
getRequiredMonitorService
in interface BuildStep
buildDependencyGraph
public void buildDependencyGraph(AbstractProject owner,
DependencyGraph graph)
- Description copied from interface:
DependencyDeclarer
- Invoked from
AbstractProject.buildDependencyGraph(DependencyGraph)
.
- Specified by:
buildDependencyGraph
in interface DependencyDeclarer
- Parameters:
owner
- The project that owns the publishers, builders, etc.
This information is conceptually redundant, as those objects are
only configured against the single owner, but this information is
nevertheless passed in since often owner information is not recorded.
Never null.graph
- The dependency graph being built. Never null.
Copyright © 2004-2013. All Rights Reserved.