[JENKINS-31153] Rename Workflow to Pipeline

README.md

@@ -1,12 +1,12 @@
 # Introduction
 
-This repository is a home for snippets, tips and tricks and examples of scripting for the [Jenkins Workflow plugin](https://github.com/jenkinsci/workflow-plugin/blob/master/README.md).
+This repository is a home for snippets, tips and tricks and examples of scripting for the [Jenkins Pipeline plugin](https://github.com/jenkinsci/workflow-plugin/blob/master/README.md).
 
 # Layout
 
 The repository is broken up into four directories currently:
 
-* *workflow-examples* - for general Workflow examples.
+* *pipeline-examples* - for general Pipeline examples.
 * *global-library-examples* - for examples of how to write and use the global library on a Jenkins master.
 * *jenkinsfile-examples* - for examples of using `Jenkinsfile`s checked into repositories.
 * *docs* - for documentation, guides and other non-code content.

jenkinsfile-examples/README.md

@@ -1,3 +1,3 @@
 # Jenkinsfile examples
 
-This directory contains example Jenkinsfiles, which are used with the Multibranch Workflow functionality, or the Workflow script from SCM functionality.
+This directory contains example Jenkinsfiles, which are used with the Pipeline Multibranch functionality, or the Pipeline script from SCM functionality.

pipeline-examples/README.md

@@ -0,0 +1,3 @@
+# Pipeline examples
+
+This directory contains various Pipeline examples, showing how to use specific plugins, how the Pipeline DSL works, and more.

workflow-examples/get-build-cause/README.md → pipeline-examples/get-build-cause/README.md

@@ -1,6 +1,6 @@
 # Synopsis
-Shows how to get the Cause(s) of a Workflow build from within the
-Workflow script.
+Shows how to get the Cause(s) of a Pipeline build from within the
+Pipeline script.
 
 # Credit
 Based on Stackoverflow answer at http://stackoverflow.com/questions/33587927/how-to-get-cause-in-workflow

workflow-examples/get-build-cause/getBuildCause.groovy → pipeline-examples/get-build-cause/getBuildCause.groovy

@@ -1,4 +1,4 @@
-// There is no direct access to the build Causes from the workflow, but you can
+// There is no direct access to the build Causes from the Pipeline, but you can
 // get this by using the `currentBuild.rawBuild` variable, as shown below.
 
 // Get all Causes for the current build

pipeline-examples/gitcommit/README.md

@@ -0,0 +1,7 @@
+# Synopsis
+Demonstrate how to expose the git_commit to a Pipeline job.
+
+# Background
+
+The git plugin exposes some environment variables to a freestyle job that are not currently exposed to a Pipeline job.
+Here's how to recover that ability using a git command and Pipeline's readFile() function.

workflow-examples/gitcommit/gitcommit.groovy → pipeline-examples/gitcommit/gitcommit.groovy

@@ -1,15 +1,15 @@
-// These should all be performed at the point where you've 
+// These should all be performed at the point where you've
 // checked out your sources on the slave. A 'git' executable
 // must be available.
 // Most typical, if you're not cloning into a sub directory
 sh('git rev-parse HEAD > GIT_COMMIT')
 git_commit=readFile('GIT_COMMIT')
-// short SHA, possibly better for chat notifications, etc. 
+// short SHA, possibly better for chat notifications, etc.
 short_commit=git_commit.take(6)
 
-//create a GIT_COMMIT file in workspace and read back into a string in workflow
+//create a GIT_COMMIT file in workspace and read back into a string in Pipeline
 // If you have your sources checked out in a 'src' subdir
 sh('cd src && git rev-parse HEAD > GIT_COMMIT')
 git_commit=readFile('src/GIT_COMMIT')
-// short SHA, possibly better for chat notifications, etc. 
+// short SHA, possibly better for chat notifications, etc.
 short_commit=git_commit.take(6)

workflow-examples/jobs-in-parallel/jobs_in_parallel.groovy → pipeline-examples/jobs-in-parallel/jobs_in_parallel.groovy

@@ -3,18 +3,17 @@ def branches = [:]
 
 //running the job 4 times concurrently
 //the dummy parameter is for preventing mutation of the parameter before the execution of the closure.
-//we have to assign it outside the closure or it will run the job multiple times with the same paraemter "4"
-//and jenkins will unite them into a single run of the job 
+//we have to assign it outside the closure or it will run the job multiple times with the same parameter "4"
+//and jenkins will unite them into a single run of the job
 
 for (int i = 0; i < 4; i++) {
   branches["branch${i}"] = {
 //Parameters:
 //param1 : an example string parameter for the triggered job.
-//dummy: a parameter used to prevent triggering the job with the same paramters value. this parameter has to accept a different value
+//dummy: a parameter used to prevent triggering the job with the same parameters value. this parameter has to accept a different value
 //each time the job is triggered.
-    build job: 'test_jobs', parameters: [[$class: 'StringParameterValue', name: 'param1', value:   
+    build job: 'test_jobs', parameters: [[$class: 'StringParameterValue', name: 'param1', value:
       'test_param'], [$class: 'StringParameterValue', name:'dummy', value: "${i}"]]
     }
-} 
+}
 parallel branches
-

workflow-examples/parallel-from-list/README.md → pipeline-examples/parallel-from-list/README.md

@@ -5,7 +5,7 @@ a map of steps to be run with the parallel command.
 
 # Caveats
 
-* Due to limitations in Workflow - i.e.,
+* Due to limitations in Pipeline - i.e.,
 [JENKINS-26481](https://issues.jenkins-ci.org/browse/JENKINS-26481) -
 it's not really possible to use Groovy closures or syntax that depends
 on closures, so you can't do the Groovy standard of using
@@ -16,4 +16,3 @@ school counter-based for loops.
 * There is no need for the generation of the step itself to be in a
 separate method. I've opted to do so here to show how to return a step
 closure from a method.
-

workflow-examples/push-git-repo/README.md → pipeline-examples/push-git-repo/README.md

@@ -1,14 +1,14 @@
 # Synopsis
 
 This demonstrates how to push a tag (or branch, etc) to a remote Git
-repository from within a Workflow job. Currently it only contains an
+repository from within a Pipeline job. Currently it only contains an
 example for pushing using username and password to authenticate.
 
 # Note
 
 This is not ideal - there is an open JIRA,
 https://issues.jenkins-ci.org/browse/JENKINS-28335, for getting the
-GitPublisher Jenkins functionality working with Workflow.
+GitPublisher Jenkins functionality working with Pipeline.
 
 # Credit
 

workflow-examples/push-git-repo/pushGitRepo.Groovy → pipeline-examples/push-git-repo/pushGitRepo.Groovy

@@ -1,7 +1,7 @@
 // This is currently the best way to push a tag (or a branch, etc) from a
-// Workflow job. It's not ideal - https://issues.jenkins-ci.org/browse/JENKINS-28335
+// Pipeline job. It's not ideal - https://issues.jenkins-ci.org/browse/JENKINS-28335
 // is an open JIRA for getting the GitPublisher Jenkins functionality working
-// with Workflow.
+// with Pipeline.
 
 // credentialsId here is the credentials you have set up in Jenkins for pushing
 // to that repository using username and password.
@@ -12,4 +12,4 @@ withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'MyID',
 }
 
 // There isn't as trivial a way to override the ssh key if you want to push that
-// way, but I hope to add that here once I find a reasonable approach.
+// way, but I hope to add that here once I find a reasonable approach.

workflow-examples/unstash-different-dir/unstashDifferentDir.groovy → pipeline-examples/unstash-different-dir/unstashDifferentDir.groovy

@@ -27,9 +27,9 @@ node('second-node') {
     }
 
     // Look, no output directory under the root!
-    // pwd() outputs the current directory Workflow is running in.
+    // pwd() outputs the current directory Pipeline is running in.
     sh "ls -la ${pwd()}"
 
     // And look, output directory is there under first-stash!
     sh "ls -la ${pwd()}/first-stash"
-}
+}