|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||
public interface BuildStep
One step of the whole build process.
These objects are persisted as a part of Project by XStream.
The save operation happens without any notice, and the restore operation
happens without calling the constructor, just like Java serialization.
So generally speaking, derived classes should use instance variables only for keeping configuration. You can still store objects you use for processing, like a parser of some sort, but they need to be marked as transient, and the code needs to be aware that they might be null (which is the case when you access the field for the first time the object is restored.)
Build steps are instantiated when the user saves the job configuration, and sticks around in memory until the job configuration is overwritten.
| Nested Class Summary | |
|---|---|
static class |
BuildStep.PublisherList
List of publisher descriptor. |
| Field Summary | |
|---|---|
static List<Descriptor<Builder>> |
BUILDERS
Deprecated. as of 1.286. Use Builder.all() for read access, and use
Extension for registration. |
static BuildStep.PublisherList |
PUBLISHERS
Deprecated. as of 1.286. Use Publisher.all() for read access, and use
Extension for registration. |
| Method Summary | |
|---|---|
Action |
getProjectAction(AbstractProject<?,?> project)
Deprecated. as of 1.341. Use getProjectActions(AbstractProject) instead. |
Collection<? extends Action> |
getProjectActions(AbstractProject<?,?> project)
Returns action objects if this BuildStep has actions
to contribute to a Project. |
BuildStepMonitor |
getRequiredMonitorService()
Declares the scope of the synchronization monitor this BuildStep expects from outside. |
boolean |
perform(AbstractBuild<?,?> build,
Launcher launcher,
BuildListener listener)
Runs the step over the given build and reports the progress to the listener. |
boolean |
prebuild(AbstractBuild<?,?> build,
BuildListener listener)
Runs before the build begins. |
| Field Detail |
|---|
static final List<Descriptor<Builder>> BUILDERS
Builder.all() for read access, and use
Extension for registration.
static final BuildStep.PublisherList PUBLISHERS
Publisher.all() for read access, and use
Extension for registration.
BuildStep.PublisherList.addNotifier(Descriptor),
BuildStep.PublisherList.addRecorder(Descriptor)| Method Detail |
|---|
boolean prebuild(AbstractBuild<?,?> build,
BuildListener listener)
Using the return value to indicate success/failure should
be considered deprecated, and implementations are encouraged
to throw AbortException to indicate a failure.
boolean perform(AbstractBuild<?,?> build,
Launcher launcher,
BuildListener listener)
throws InterruptedException,
IOException
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.
Using the return value to indicate success/failure should
be considered deprecated, and implementations are encouraged
to throw AbortException to indicate a failure.
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.
IOException - If the implementation wants to abort the processing when an IOException
happens, it can simply propagate the exception to the caller. This will cause
the build to fail, with the default error message.
Implementations are encouraged to catch IOException on its own to
provide a better error message, if it can do so, so that users have better
understanding on why it failed.Action getProjectAction(AbstractProject<?,?> project)
getProjectActions(AbstractProject) instead.
Collection<? extends Action> getProjectActions(AbstractProject<?,?> project)
BuildStep has actions
to contribute to a Project.
Project calls this method for every BuildStep that
it owns when the rendering is requested.
This action can have optional jobMain.jelly view, which will be aggregated into the main panel of the job top page. The jelly file should have an <h2> tag that shows the section title, followed by some block elements to render the details of the section.
project - Project that owns this build step,
since BuildStep object doesn't usually have this "parent" pointer.
BuildStepMonitor getRequiredMonitorService()
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
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
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
CheckPoints
to perform necessary synchronizations.
If you are migrating BuildStep implementations written for earlier versions of Hudson,
here's what you can do:
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.
Run.getPreviousBuild()), then you can return BuildStepMonitor.NONE without making further
code changes and you are done with migration.
Actions 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.
BuildStepMonitor.NONE and use
CheckPoints directly in your code. The general idea is to call CheckPoint.block() before
you try to access the state from the previous build.
For plugins written against earlier versions of Hudson, calling this method results in
AbstractMethodError.
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||