[JENKINS-31153] More renames.

COMPATIBILITY.md

@@ -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
 

README.md

@@ -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
 
@@ -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)
 
@@ -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.

aggregator/src/main/resources/index.jelly

@@ -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>

api/src/main/resources/index.jelly

@@ -24,5 +24,5 @@
 
 <?jelly escape-by-default='true'?>
 <div>
-  Plugin that defines workflow API.
+  Plugin that defines Pipeline API.
 </div>

basic-steps/CORE-STEPS.md

@@ -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 {
@@ -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
@@ -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') {

basic-steps/src/main/resources/index.jelly

@@ -25,5 +25,5 @@ THE SOFTWARE.
 
 <?jelly escape-by-default='true'?>
 <div>
-    Commonly used steps for workflows.
+    Commonly used steps for Pipelines.
 </div>

basic-steps/src/main/resources/org/jenkinsci/plugins/workflow/steps/CatchErrorStep/help.html

@@ -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>
@@ -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:
@@ -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>

basic-steps/src/main/resources/org/jenkinsci/plugins/workflow/steps/CoreStep/help.html

@@ -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>

basic-steps/src/main/resources/org/jenkinsci/plugins/workflow/steps/CoreWrapperStep/help.html

@@ -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>

basic-steps/src/main/resources/org/jenkinsci/plugins/workflow/steps/SleepStep/help.html

@@ -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>

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
@@ -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.
 
@@ -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
@@ -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()
@@ -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"
@@ -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 {
@@ -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";
@@ -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:
 
@@ -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

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>

cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/LoadStep.java

@@ -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";
         }
     }
 

cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java

@@ -225,7 +225,7 @@ public boolean takesImplicitBlockArgument() {
 
         @Override
         public String getDisplayName() {
-            return "Execute sub-workflows in parallel";
+            return "Execute parts of a Pipeline in parallel";
         }
     }
 }

cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsFlowDefinition/help-script.html

@@ -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'

cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/help-scm.html

@@ -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>

cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/EnvActionImpl/Binder/help.jelly

@@ -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>
@@ -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>

cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/steps/LoadStep/help.html

@@ -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>

demo/Dockerfile

@@ -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 [email protected] -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 [email protected] -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

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>
@@ -11,4 +11,4 @@
       <level>500</level>
     </target>
   </targets>
-</log>
+</log>