public interface BuildStep
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
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.)
|Modifier and Type||Interface and Description|
List of publisher descriptor.
|Modifier and Type||Field and Description|
as of 1.286. Use
as of 1.286. Use
|Modifier and Type||Method and Description|
as of 1.341. Use
Returns action objects if this
Declares the scope of the synchronization monitor this
Runs the step over the given build and reports the progress to the listener.
Runs before the build begins.
static final List<Descriptor<Builder>> BUILDERS
Builder.all()for read access, and use
static final BuildStep.PublisherList PUBLISHERS
Publisher.all()for read access, and use
boolean prebuild(AbstractBuild<?,?> build, BuildListener listener)
boolean perform(AbstractBuild<?,?> build, Launcher launcher, BuildListener listener) throws InterruptedException, IOException
A plugin can contribute the action object to
Build#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.
InterruptedException- If the build is interrupted by the user (in an attempt to abort the build.) Normally the
BuildStepimplementations may simply forward the exception it got from its lower-level functions.
IOException- If the implementation wants to abort the processing when an
IOExceptionhappens, 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
IOExceptionon 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)
Collection<? extends Action> getProjectActions(AbstractProject<?,?> project)
BuildStephas actions to contribute to a
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.
Projectthat owns this build step, since
BuildStepobject doesn't usually have this "parent" pointer.
BuildStepexpects 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
BuildStepis only executed after the previous build is fully completed (thus fully restoring the earlier semantics of one build at a time.)
BuildStepis 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.
CheckPoints to perform necessary synchronizations.
If you are migrating
BuildStep implementations written for earlier versions of Hudson,
here's what you can do:
BuildStepMonitor.BUILDto 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.NONEwithout 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.STEPscope synchronization. Return it from this method ,and you are done with migration without any further code changes.
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
Copyright © 2004-2015 Hudson. All Rights Reserved.