s/jenkins.groovy/Jenkinsfile/g

TUTORIAL.md

@@ -683,14 +683,14 @@ The difference is that you do not configure a single branch, but a _set_ of bran
 
 For example, if you select _Git_ as the branch source (Subversion and Mercurial are also supported already), you will be prompted for the usual connection information,
 but then rather than a fixed refspec you will enter a branch name pattern (use the defaults to look for any branch).
-Jenkins expects to find a script named `jenkins.groovy` in branches it can build.
+Jenkins expects to find a script named `Jenkinsfile` in branches it can build.
 From this script, the command `checkout scm` suffices to check out your project’s source code inside some `node {}`.
 
 Say you start with just a `master` branch, then you want to experiment with some changes, so you `git checkout -b newfeature` and push some commits.
 Jenkins will automatically detect the new branch in your repository and create a new subproject for it—with its own build history unrelated to trunk, so no one will mind if it has red/yellow balls for a while.
 (If you like, you can ask for the subproject to be automatically removed after the branch is merged and deleted.)
 
-The neat thing is that if you want to change your Workflow script—for example, to add a new Jenkins publisher step corresponding to reports your `Makefile`/`pom.xml`/etc. is newly creating—you just edit `jenkins.groovy` in your change.
+The neat thing is that if you want to change your Workflow script—for example, to add a new Jenkins publisher step corresponding to reports your `Makefile`/`pom.xml`/etc. is newly creating—you just edit `Jenkinsfile` in your change.
 The Workflow script is always synchronized with the rest of the source code you are working on: `checkout scm` checks out the same revision as the script is loaded from.
 
 # Exploring available steps