Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Merge pull request #314 from jglick/more-renames
[JENKINS-31153] More renames
Originally-Committed-As: 3094947f45f0b7d7c18d7f3be03b39eceffeee5b
  • Loading branch information
jglick committed Jan 22, 2016
2 parents d2d5774 + 6a77428 commit 0643d8e
Show file tree
Hide file tree
Showing 6 changed files with 19 additions and 19 deletions.
20 changes: 10 additions & 10 deletions basic-steps/CORE-STEPS.md
Expand Up @@ -3,12 +3,12 @@
Many Jenkins plugins add builders or post-build actions (collectively, _build steps_) for use in freestyle and similar projects.
(Jenkins core also adds a few of these, though most have been split off into their own plugins or could be split off.)

In many cases these build steps would be valuable to use from workflows, but it would be overkill to define a separate Workflow-only step.
Therefore selected build steps can be called directly from workflows.
In many cases these build steps would be valuable to use from Pipelines, but it would be overkill to define a separate Pipeline-only step.
Therefore selected build steps can be called directly from Pipelines.

# Syntax

As an example, you can write a flow:
As an example, you can write a Pipeline script:

```groovy
node {
Expand All @@ -19,28 +19,28 @@ node {

Here we are running the standard _Archive the artifacts_ post-build action (`hudson.tasks.ArtifactArchiver`),
and configuring the _Files to archive_ property (`artifacts`) to archive our file `something` produced in an earlier step.
The easiest way to see what class and field names to use is to use the _Snippet Generator_ feature in the workflow configuration page.
The easiest way to see what class and field names to use is to use the _Snippet Generator_ feature in the Pipeline configuration page.

See the [compatibility list](../COMPATIBILITY.md) for the list of currently supported steps.

# Interacting with build status

Builders generally have a simple mode of operation: they run, and either pass or fail.
So you can call these at any point in your flow.
So you can call these at any point in your pipeline.

Post-build actions (also known as _publishers_) are divided into two classes:

* _Recorders_ like the JUnit publisher add something to the build, and might affect its status.
* _Notifiers_ like the mailer cannot affect the build’s status, though they may behave differently depending on its status.

When a recorder is run from a flow, it might set the build’s status (for example to unstable), but otherwise is likely to work intuitively.
Running a notifier is trickier since normally a flow in progress has no status yet, unlike a freestyle project whose status is determined before the notifier is called.
When a recorder is run from a pipeline, it might set the build’s status (for example to unstable), but otherwise is likely to work intuitively.
Running a notifier is trickier since normally a pipeline in progress has no status yet, unlike a freestyle project whose status is determined before the notifier is called.
To help interoperate better with these, you can use the `catchError` step, or manually set a build status using `currentBuild.result`.
See the help for the `catchError` step for examples.

## Plain catch blocks

Some important publishers also have dedicated Workflow steps, so that you can use a more flexible idiom.
Some important publishers also have dedicated Pipeline steps, so that you can use a more flexible idiom.
For example, `mail` lets you unconditionally send mail of your choice:

```groovy
Expand All @@ -63,10 +63,10 @@ For that, check if `currentBuild.previousBuild` exists, what its `.result` is, e
# Build wrappers

The `wrap` step may be used to run a build wrapper defined originally for freestyle projects.
In a workflow, any block of code (inside `node`) may be wrapped in this way, not necessarily the whole build.
In a Pipeline, any block of code (inside `node`) may be wrapped in this way, not necessarily the whole build.

For example, the Xvnc plugin allows a headless build server to run GUI tests by allocating an in-memory-only X11 display.
To use this plugin from a workflow, assuming a version with the appropriate update:
To use this plugin from a Pipeline, assuming a version with the appropriate update:

```groovy
node('linux') {
Expand Down
2 changes: 1 addition & 1 deletion basic-steps/src/main/resources/index.jelly
Expand Up @@ -25,5 +25,5 @@ THE SOFTWARE.

<?jelly escape-by-default='true'?>
<div>
Commonly used steps for workflows.
Commonly used steps for Pipelines.
</div>
@@ -1,6 +1,6 @@
<div>
If the body throws an exception, mark the build as a failure, but nonetheless
continue to execute the workflow from the statement following the <code>catchError</code> step.
continue to execute the Pipeline from the statement following the <code>catchError</code> step.
This is <em>only</em> necessary when using certain post-build actions (notifiers)
originally defined for freestyle projects which pay attention to the result of the ongoing build.
<p><pre>
Expand All @@ -11,7 +11,7 @@
step([$class: 'Mailer', recipients: 'admin@somewhere'])
}
</pre>
<p>If the shell step fails, the flow build’s status will be set to failed, so that the subsequent mail step will see that this build is failed.
<p>If the shell step fails, the Pipeline build’s status will be set to failed, so that the subsequent mail step will see that this build is failed.
In the case of the mail sender, this means that it will send mail.
(It may also send mail if this build <em>succeeded</em> but previous ones failed, and so on.)
Even in that case, this step can be replaced by the following idiom:
Expand Down Expand Up @@ -40,7 +40,7 @@
}
echo 'Printed whether above succeeded or failed.'
}
// …and the workflow as a whole succeeds
// …and the pipeline as a whole succeeds
</pre>
<p>See <a href="https://github.com/jenkinsci/workflow-plugin/blob/master/basic-steps/CORE-STEPS.md#interacting-with-build-status" target="_blank">this document</a> for background.
</div>
Expand Up @@ -4,6 +4,6 @@
Just select the build step to call from the dropdown list and configure it as needed.
</p>
<p>
Note that only workflow compatible steps will be shown in the list.
Note that only Pipeline-compatible steps will be shown in the list.
</p>
</div>
</div>
Expand Up @@ -4,6 +4,6 @@
Just select the wrapper to use from the dropdown list and configure it as needed. Everything inside the wrapper block is under its effect.
</p>
<p>
Note that only workflow compatible wrappers will be shown in the list.
Note that only Pipeline-compatible wrappers will be shown in the list.
</p>
</div>
</div>
@@ -1,5 +1,5 @@
<div>
Simply pauses the workflow until the given amount of time has expired.
Simply pauses the Pipeline build until the given amount of time has expired.
Equivalent to (on Unix) <code>sh 'sleep …'</code>.
May be used to pause one branch of <code>parallel</code> while another proceeds.
</div>

0 comments on commit 0643d8e

Please sign in to comment.