Skip to content
This repository has been archived by the owner on Dec 15, 2021. It is now read-only.

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
  • Loading branch information
jglick committed Jan 22, 2016
2 parents 3aaaabe + dddc636 commit 3094947
Show file tree
Hide file tree
Showing 29 changed files with 118 additions and 118 deletions.
2 changes: 1 addition & 1 deletion COMPATIBILITY.md
Expand Up @@ -339,7 +339,7 @@ Replace `Trigger<AbstractProject>` with `Trigger<X>` where `X` is `Job` or perha

## Clouds

Do not necessarily need any special integration, but are encouraged to use `OnceRetentionStrategy` from `durable-task` to allow flow builds to survive restarts.
Do not necessarily need any special integration, but are encouraged to use `OnceRetentionStrategy` from `durable-task` to allow Pipeline builds to survive restarts.

## Custom steps

Expand Down
8 changes: 4 additions & 4 deletions README.md
Expand Up @@ -23,7 +23,7 @@ If Jenkins is restarted (intentionally, or because of a crash) while your Pipeli
This applies to external processes (shell scripts) so long as the slave can be reattached, and losing the slave connection temporarily is not fatal either.

Pipelines can pause in the middle and wait for a human to approve something, or enter some information.
Executors need not be consumed while the flow is waiting.
Executors need not be consumed while the Pipeline is waiting.

## Pipeline stages

Expand Down Expand Up @@ -85,7 +85,7 @@ Webinar _Orchestrating the Continuous Delivery Process in Jenkins with Workflow_

[Reusing build steps from freestyle projects](basic-steps/CORE-STEPS.md)

[Using version control from a workflow](scm-step/README.md)
[Using version control from a Pipeline](scm-step/README.md)

[Using the global Groovy class library](cps-global-lib/README.md)

Expand Down Expand Up @@ -121,12 +121,12 @@ While the implementation is divided into a number of plugins, for ease of protot

* `step-api` defines a generic build step interface (not specific to pipelines) that many plugins could in the future depend on.
* `basic-steps` add some generic step implementations. There is [more documentation there](basic-steps/CORE-STEPS.md).
* `api` defines the essential aspects of pipelines and their executions. In particular, the engine running a flow is extensible and so could in the future support visual orchestration languages.
* `api` defines the essential aspects of pipelines and their executions. In particular, the engine running a Pipeline is extensible and so could in the future support visual orchestration languages.
* `support` adds general implementations of some internals needed by pipelines, such as storing state.
* `job` provides the actual job type and top-level UI for defining and running pipelines.
* `durable-task-step` uses the `durable-task` plugin to define a shell script step that can survive restarts.
* `scm-step` adds SCM-related steps. There is [more documentation there](scm-step/README.md).
* `cps` is the flow engine implementation based on the Groovy language, and supporting long-running pipelines using a _continuation passing style_ transformation of the script.
* `cps` is the Pipeline engine implementation based on the Groovy language, and supporting long-running pipelines using a _continuation passing style_ transformation of the script.
* `cps-global-lib` adds a Git-backed repository for Groovy libraries available to scripts.
* `stm` is a simple engine implementation using a _state transition machine_, less intended for end users than as a reference for how engines can work. Currently only partly implemented.
* `aggregator` is a placeholder plugin allowing you to `mvn hpi:run` and see everything working together, as well as holding integration tests.
94 changes: 47 additions & 47 deletions TUTORIAL.md

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion aggregator/src/main/resources/index.jelly
Expand Up @@ -24,5 +24,5 @@

<?jelly escape-by-default='true'?>
<div>
Collects all workflow-related plugins as dependencies to make them easier to install and demonstrate.
Collects all Pipeline-related plugins as dependencies to make them easier to install and demonstrate.
</div>
2 changes: 1 addition & 1 deletion api/src/main/resources/index.jelly
Expand Up @@ -24,5 +24,5 @@

<?jelly escape-by-default='true'?>
<div>
Plugin that defines workflow API.
Plugin that defines Pipeline API.
</div>
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>
32 changes: 16 additions & 16 deletions cps-global-lib/README.md
@@ -1,11 +1,11 @@
# Workflow Global Library
# Pipeline Global Library

When you have multiple workflow jobs, you often want to share some parts of the workflow
scripts between them to keep workflow scripts [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself).
When you have multiple Pipeline jobs, you often want to share some parts of the Pipeline
scripts between them to keep Pipeline scripts [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself).
A very common use case is that you have many projects that are built in the similar way.

This plugin adds that functionality by creating a "shared library script" Git repository inside Jenkins.
Every workflow script in your Jenkins see these shared library scripts in their classpath.
Every Pipeline script in your Jenkins see these shared library scripts in their classpath.


### Directory structure
Expand All @@ -22,16 +22,16 @@ The directory structure of the shared library repository is as follows:
+- foo.txt # help for 'foo' variable/function

The `src` directory should look like standard Java source directory structure.
This directory is added to the classpath when executing workflows.
This directory is added to the classpath when executing Pipelines.

The `vars` directory hosts scripts that define global variables accessible from
workflow scripts.
Pipeline scripts.
The basename of each `*.groovy` file should be a Groovy (~ Java) identifier, conventionally `camelCased`.
The matching `*.txt`, if present, can contain documentation, processed through the system’s configured markup formatter
(so may really be HTML, Markdown, etc., though the `txt` extension is required).

The groovy source files in these directories get the same sandbox / CPS
transformation just like your workflow scripts.
transformation just like your Pipeline scripts.

Other directories under the root are reserved for future enhancements.

Expand Down Expand Up @@ -80,8 +80,8 @@ class Point {

However classes written like this cannot call step functions like `sh` or `git`.
More often than not, what you want to define is a series of functions that in turn invoke
other workflow step functions. You can do this by not explicitly defining the enclosing class,
just like your main workflow script itself:
other Pipeline step functions. You can do this by not explicitly defining the enclosing class,
just like your main Pipeline script itself:

```groovy
// src/org/foo/Zot.groovy
Expand All @@ -92,7 +92,7 @@ def checkOutFrom(repo) {
}
```

You can then call such function from your main workflow script like this:
You can then call such function from your main Pipeline script like this:

```groovy
def z = new org.foo.Zot()
Expand All @@ -107,12 +107,12 @@ define the `call` method:
```groovy
// vars/helloWorld.groovy
def call(name) {
// you can call any valid step functions from your code, just like you can from workflow scripts
// you can call any valid step functions from your code, just like you can from Pipeline scripts
echo "Hello world, ${name}"
}
```

Then your workflow can call this function like this:
Then your Pipeline can call this function like this:

```groovy
helloWorld "Joe"
Expand All @@ -131,7 +131,7 @@ def call(Closure body) {
}
```

Your workflow can call this function like this:
Your Pipeline can call this function like this:

```groovy
windows {
Expand Down Expand Up @@ -159,7 +159,7 @@ def say(name) {
}
```

Then your workflow can call these functions like this:
Then your Pipeline can call these functions like this:

```groovy
acme.foo = "5";
Expand All @@ -168,7 +168,7 @@ acme.say "Joe" // print "Hello world, Joe"
```

### Define more structured DSL
If you have a lot of workflow jobs that are mostly similar, the global function/variable mechanism gives you
If you have a lot of Pipeline jobs that are mostly similar, the global function/variable mechanism gives you
a handy tool to build a higher-level DSL that captures the similarity. For example, all Jenkins plugins are
built and tested in the same way, so we might write a global function named `jenkinsPlugin` like this:

Expand All @@ -190,7 +190,7 @@ def call(body) {
}
```

With this, the workflow script will look a whole lot simpler, to the point that people who don't know anything
With this, the Pipeline script will look a whole lot simpler, to the point that people who don't know anything
about Groovy can write it:

```groovy
Expand Down
2 changes: 1 addition & 1 deletion cps-global-lib/src/main/resources/index.jelly
@@ -1,4 +1,4 @@
<?jelly escape-by-default='true'?>
<div>
Global shared library for workflow scripts
Global shared library for Pipeline scripts.
</div>
Expand Up @@ -38,7 +38,7 @@ public String getFunctionName() {

@Override
public String getDisplayName() {
return "Evaluate a Groovy source file into the workflow script";
return "Evaluate a Groovy source file into the Pipeline script";
}
}

Expand Down
Expand Up @@ -225,7 +225,7 @@ public boolean takesImplicitBlockArgument() {

@Override
public String getDisplayName() {
return "Execute sub-workflows in parallel";
return "Execute in parallel";
}
}
}
@@ -1,5 +1,5 @@
<p>
Groovy script defining this workflow. A quick example:
Groovy script defining this Pipeline. A quick example:
</p>
<pre>node {
sh 'echo hello world'
Expand Down
@@ -1,7 +1,7 @@
<div>
Specify where to obtain a source code repository containing your Groovy script.
It will be checked out somewhere on the Jenkins master and used to load your workflow script.
(If you wish to use other files from the same repository during your flow,
It will be checked out somewhere on the Jenkins master and used to load your Pipeline script.
(If you wish to use other files from the same repository during your Pipeline,
you will need to check them out separately on some slave;
this checkout cannot be reused.)
</div>
Expand Up @@ -16,13 +16,13 @@ node {
and from upstream Pipeline builds using the <code>build</code> step.
</p>
<p>
However any variables set this way are global to the workflow build.
However any variables set this way are global to the Pipeline build.
For variables with node-specific content (such as file paths),
you should instead use the <code>withEnv</code> step,
to bind the variable only within a <code>node</code> block.
</p>
<p>
A set of environment variables are made available to all Jenkins projects, including workflows.
A set of environment variables are made available to all Jenkins projects, including Pipelines.
The following is a general list of variables (by name) that are available;
see the notes below the list for Pipeline-specific details.
</p>
Expand All @@ -31,7 +31,7 @@ node {
<st:include it="${ec}" page="buildEnv" optional="true"/>
</j:forEach>
<p>
The following variables are currently unavailable inside a workflow script:
The following variables are currently unavailable inside a Pipeline script:
</p>
<ul>
<li><code>NODE_LABELS</code></li>
Expand Down
Expand Up @@ -4,14 +4,14 @@
The loaded file can contain statements at top level or just load and run a closure. For example:
</p>
<pre>
def flow
def pipeline
node('slave') {
flow = load 'flow.groovy'
flow.functionA()
pipeline = load 'pipeline.groovy'
pipeline.functionA()
}
flow.functionB()
pipeline.functionB()
</pre>
<p>
Where <code>flow.groovy</code> defines functionA and functionB functions (among others) before ending with <code>return this;</code>
Where <code>pipeline.groovy</code> defines functionA and functionB functions (among others) before ending with <code>return this;</code>
<p>
</div>
2 changes: 1 addition & 1 deletion demo/Dockerfile
Expand Up @@ -28,7 +28,7 @@ USER root
RUN chown -R jenkins.jenkins /tmp/files
USER jenkins
WORKDIR /tmp/files
RUN git init --bare repo && cd repo-wc && git init && git add . && git -c user.email=demo@jenkins-ci.org -c user.name="Workflow Demo" commit -m 'demo' && git push ../repo master
RUN git init --bare repo && cd repo-wc && git init && git add . && git -c user.email=demo@jenkins-ci.org -c user.name="Pipeline Demo" commit -m 'demo' && git push ../repo master

# Prepare local Maven repo. Note that $JENKINS_HOME is a volume so we cannot populate it now.
RUN echo '<settings><mirrors><mirror><id>central</id><url>http://repo.jenkins-ci.org/simple/repo1-cache/</url><mirrorOf>central</mirrorOf></mirror></mirrors><localRepository>/usr/share/jenkins/ref/.m2/repository</localRepository></settings>' > /tmp/files/settings.xml
Expand Down
4 changes: 2 additions & 2 deletions demo/JENKINS_HOME/log/Workflow.xml
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<log>
<name>Workflow</name>
<name>Pipeline</name>
<targets>
<target>
<name>org.jenkinsci.plugins.workflow</name>
Expand All @@ -11,4 +11,4 @@
<level>500</level>
</target>
</targets>
</log>
</log>

0 comments on commit 3094947

Please sign in to comment.