Skip to content
Permalink
Browse files

[JENKINS-31153] More references were replaced

  • Loading branch information
recena committed Jan 14, 2016
1 parent e26b879 commit e9785b290387f6b809a623097e83722c05d3c106
@@ -25,5 +25,5 @@ THE SOFTWARE.

<?jelly escape-by-default='true'?>
<div>
Workflow steps running external processes that may survive a Jenkins restart or slave reconnection.
Pipeline steps running external processes that may survive a Jenkins restart or slave reconnection.
</div>
@@ -25,7 +25,7 @@ THE SOFTWARE.

<?jelly escape-by-default='true'?>
<j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:l="/lib/layout">
<l:layout title="${it.run.fullDisplayName} Workflow Steps">
<l:layout title="${it.run.fullDisplayName} Pipeline steps">
<st:include page="sidepanel.jelly" it="${it.run}"/>
<l:main-panel>
<st:include it="${it.flowGraph}" page="ajax"/>
@@ -25,5 +25,5 @@ THE SOFTWARE.

<?jelly escape-by-default='true'?>
<div>
Defines a project type for multibranch workflows.
Defines a project type for multibranch pipelines.
</div>
@@ -1,12 +1,12 @@
# Introduction

This plugin allows workflows to use standard Jenkins SCM plugins to check out source code.
This plugin allows pipelines to use standard Jenkins SCM plugins to check out source code.
The goals are the maximum possible compatibility with existing plugins, and great flexibility for script authors.

# Features

A freestyle project has a single SCM configured in the UI that governs the one and only workspace for the build.
A workflow can be configured similarly, but the SCM definition becomes a regular step in its script.
A Pipeline can be configured similarly, but the SCM definition becomes a regular step in its script.
In the simplest case you would just do an SCM clone/update at the start of your script, as soon as you have allocated a slave with a workspace:

```
@@ -24,7 +24,7 @@ Jenkins will clone the repository into the workspace and continue with your scri
While freestyle projects can use the Multiple SCMs plugin to check out more than one repository,
or specify multiple locations in SCM plugins that support that (notably the Git plugin),
this support is quite limited.
In a workflow you can check out multiple SCMs, of the same or different kinds, in the same or different workspaces, wherever and whenever you like.
In a Pipeline you can check out multiple SCMs, of the same or different kinds, in the same or different workspaces, wherever and whenever you like.
For example, to check out and build several repositories in parallel, each on its own slave:

```
@@ -49,15 +49,15 @@ This means that you can run multiple SCMs, even from a dynamic list, and get a r

## Polling

If you configure the _Poll SCM_ trigger in the workflow’s UI configuration screen, then by default Jenkins will also poll for changes according to the selected _Schedule_, and schedule new builds automatically if changes are detected.
If you configure the _Poll SCM_ trigger in the Pipeline’s UI configuration screen, then by default Jenkins will also poll for changes according to the selected _Schedule_, and schedule new builds automatically if changes are detected.
(Note that this configuration is not part of the flow script, because it affects activities that Jenkins runs outside of the flow.)
Some SCMs allow polling with no workspace, which is ideal; others will try to lock the same slave and workspace previously used, to run polling on the slave.

To avoid polling the server repeatedly, most SCM plugins allow remote commit triggers, such as the `/git/notifyCommit?url=…` HTTP endpoint in the case of the Git plugin.
These also work with workflows, unless (as with freestyle projects) you checked _Ignore post-commit hooks_ in a _Poll SCM_ block.
These also work with Pipelines, unless (as with freestyle projects) you checked _Ignore post-commit hooks_ in a _Poll SCM_ block.
Depending on the SCM plugin, you may still need to configure a _Poll SCM_ trigger, though its _Schedule_ could be empty (or `@daily`, to serve as a fallback in case the commit triggers fail).

Polling is supported across multiple SCMs (changes in one or more will trigger a new build), and again is done according to the SCMs used in the last build of the workflow.
Polling is supported across multiple SCMs (changes in one or more will trigger a new build), and again is done according to the SCMs used in the last build of the pipeline.

You may specify `poll: false` to disable polling for an SCM checkout.

@@ -114,6 +114,6 @@ This would correspond roughly to a freestyle project whose `config.xml` includes

with no `<hudson.triggers.SCMTrigger>` (polling).

# Supporting Workflow from an SCM plugin
# Supporting Pipeline from an SCM plugin

See the [compatibility guide](../COMPATIBILITY.md#plugin-developer-guide).
@@ -25,5 +25,5 @@ THE SOFTWARE.

<?jelly escape-by-default='true'?>
<div>
Adds workflow steps to check out or update working sources from various SCMs (version control).
Adds Pipeline steps to check out or update working sources from various SCMs (version control).
</div>
@@ -1,20 +1,20 @@
# Writing Workflow steps
# Writing Pipeline steps

Plugins can implement custom Workflow steps with specialized behavior by adding a dependency on `workflow-step-api`.
Remember to ensure that your baseline Jenkins version is at least as new as that required by the version of Workflow you are depending on.
Plugins can implement custom Pipeline steps with specialized behavior by adding a dependency on `workflow-step-api`.
Remember to ensure that your baseline Jenkins version is at least as new as that required by the version of Pipeline you are depending on.
(The [changelog](../CHANGES.md) notes these baselines.)

## Creating a basic synchronous step

When a Workflow step does something quick and nonblocking, you can make a “synchronous” step.
When a Pipeline step does something quick and nonblocking, you can make a “synchronous” step.
The Groovy execution waits for it to finish.

Extend `AbstractStepImpl`.
Define mandatory parameters in a `@DataBoundConstructor`.
Define optional parameters using `@DataBoundSetter`.
(Both need matching getters.)

Create a class, conventionally a nested `public static class Execution`, and extend `AbstractSynchronousNonBlockingStepExecution` (or `AbstractSynchronousStepExecution` in older versions of Workflow or for certain trivial steps).
Create a class, conventionally a nested `public static class Execution`, and extend `AbstractSynchronousNonBlockingStepExecution` (or `AbstractSynchronousStepExecution` in older versions of Pipeline or for certain trivial steps).
Parameterize it with the desired return value of the step (or `Void` if it need not return a value).
The `run` method should do the work of the step.
You can `@Inject` the step object to access its configuration.
@@ -31,8 +31,8 @@ The descriptor can also have the usual methods complementing `config.jelly` for

## Creating an asynchronous step

For the more general case that a Workflow step might block in network or disk I/O, and might need to survive Jenkins restarts, you can use a more powerful API.
This relies on a callback system: the Workflow engine tells your step when to start, and your step tells Workflow when it is done.
For the more general case that a Pipeline step might block in network or disk I/O, and might need to survive Jenkins restarts, you can use a more powerful API.
This relies on a callback system: the Pipeline engine tells your step when to start, and your step tells Pipeline when it is done.

Extend `AbstractStepExecutionImpl` rather than `AbstractSynchronousStepExecution`.
You will be implementing a `start` method.
@@ -60,7 +60,7 @@ but generally it will need to interrupt whatever process you started.

## Creating a block-scoped step

Workflow steps can also take “closures”: a code block which they may run zero or more times, optionally with some added context.
Pipeline steps can also take “closures”: a code block which they may run zero or more times, optionally with some added context.

Override `takesImplicitBlockArgument` in your descriptor.
In `start`, or thereafter, call
@@ -82,5 +82,5 @@ You can pass various contextual objects, as per `@StepContextParameter` above.

## Using more APIs

You can also add a dependency on `workflow-api` which brings in more Workflow-specific features.
For example you can then receive a `FlowNode` as a `@StepContextParameter` and call `addAction` to customize the _Workflow Steps_ view.
You can also add a dependency on `workflow-api` which brings in more Pipeline-specific features.
For example you can then receive a `FlowNode` as a `@StepContextParameter` and call `addAction` to customize the _Pipeline Steps_ view.

0 comments on commit e9785b2

Please sign in to comment.
You can’t perform that action at this time.