Devops: Jenkins Pipeline As Code: All you need to know A - Z

1. Introduction: Hello. Everyone will come to Jenkins. Pipeline is called All You Need to Know from A to Z brought to you by accelerate askew up. This course will help to speed up your learning on how to implement pipeline escorting Jenkins effectively what it's in Texas light and what can be achieved using pipeline is code. This course is the outcome of my own personal struggles with understanding and implementing part minus court when I first started out. And I really hope that this course will help you shorten the learning curve by having everything you need. In one course. I've spent a lot of time putting together what I think is one of the few causes around on Jenkins. Pipeline is coat. I've designed this course for specifically two types of people beginners who are just starting out on Jenkins. Problem is coat and intermediate people who want a more knowledge on implementing pipeline escorting Jenkins. I have to say that this is not a setting up off Jenkins course, as it assumes that you really have some understanding of Jenkins and some programming knowledge. It would be even better if you already know groovy, but that's not a strong requirement as you would be able to follow what a groovy court is doing, and I will explain more on groovy during the course. There is a lot of content in this course, and I really believe that you will get a lot out from it. He's washed the preview videos, read the reviews, and I'll see you inside. 2. Overview of pipeline syntax: in this lecture, I want to show you this interactive Excel spreadsheet that I've meet, which I hope makes it easier for you to navigate the pipeline. Syntex. As you can see at the top left hand corner, you have the column numbers which can click on to expand the columns. You can also click on across boxes to expand about Clark section, and you can keep expending to see what the options are. For each section, we will be exploring further each section as we progress through the course. The text here is sticking form the Jenkins Pipelines in text website, so credit goes to them. Please make special note that the decorative syntax always starts with the key would pipeline and scripted Syntex starts with the key would note when you encounter problems and Google for answers and you see that some answers instead. Overflow, for example, starts with note, which is scripted syntax. You can use that answer if you are using decorative Syntex unless you are using the script block inside declarative Syntex, which we will cover later in the lectures. So please better in mind when you come across illusions in scripted Syntex, feel free to download explored a spreadsheet and I was Syria in the next lesson where we will create a basic hello World Pipeline script. 3. Helloworld pipeline script: in this lesson, we will be creating a hollow, whoa pipeline script based on what we see in the Excel spreadsheet. I just want to let you know that all of the source code for this course is available on Get up. As you can see, agents and stages are required in a basic part blind script, and within stage, you will need to define the steps section for by whatever steps you want to put in. Let me first create a new Jenkins Pipeline job. As you can see, we have set the agent to any, and we are echoing our hello world. Using the echo step, we will be covering the agents section in a later chapter, Let's know, save the job and run it. Looking at a console output, we can see the hollow world being printed out. And this concludes our hello world example 4. Declarative: Pipeline > Agent: in this lecture, we will be exploring the options available under Agents Section. As you can see, we have the option off any which informs Jenkins to run on any available agents. None, which informs Jenkins that there is no global agent. And if there are no agents, specify at a state level, then it runs on current Jenkins label, which tells Jenkins to run the script in a particular agent. We shall take a look at that Knicks for Newt. It is essentially the same as agents with a label, but also allows you to specify the location off the workspace we will explore. Also explore that later. For any we have already shown is usage in the Huddle World. Example. Let's change it to none and see how it behaves. So as you can see, the pipeline script runs on the current Jenkins set up when we do not specify an agent under stage, which is optional. Next, let's see how label works. Let's go to manage Jenkins and manage notes. As you can see, we already have a slave set up right here. Take note of the name off the sleeve. Scott's Leave one. We will need to use that for the label. Let's now go back to the Jenkins job. We're now changed the script. Appoint Toe Agent label, Slave one and rerun the job from the Consul Output. You can see that a script rent on Slave one. Let's not change just to note and also adding a new custom workspace property. This custom book space has already been created on the server site on a slave silver site. There's Rerun the job and see what happens. So it shows that is grant on Slave one. Any ren under the custom work space. So let's go back to the Excel spreadsheet for Dr and Dr Foul. We were Skip that for now. We'll cover those in a later chapter, so this concludes our section on agents. 5. Declarative: Pipeline > Stage > Steps > Script: in this lecture, we will be demonstrating how we can use the script step. The script step gives us the ability to program more complex floors beyond what the declarative Syntex allows users Groovy s to programming language. So if you want more power in your Jenkins script, you will need to learn some groovy their causes in groovy that can help you get up to speed on this in text. But I'm sure that if you come from a programming background, you can follow what the groovy court is doing in the Jenkins script in this course, and nothing that you might want to know is that you can also use declarative steps inside the script step. Let's see an example. So what this court is doing is using groovy to specify a variable colt name. And he has a simple if else statement. Print line comes from groovy as well, so you can use it to print out statements on Jenkins console and a dollar sign brackets. Name is also groovy Syntex for referencing the name Variable wing printing out the string. After that, you can see that I'm calling the sleep step, which comes from the workflow basic steps. Plug into sleep for two seconds and I'm using the echo step to print out a string. Let's run the job and see how he behaves. So you get the high Jeff slipping for two secs and and off script lines they go, I hope you find is useful. And now let's move on to the next lecture. 6. Declarative: Pipeline > Stage > Steps > Retry/Timeouts: In this lecture, we will be demonstrating using retry and timeouts in the Steps section. Together with the sleep and error steps. The retrial and timeouts are different from the ones in the options section as they apply to only a block of code and can be nested within each other or used separately. I'm showing thes two steps so that you are aware that time outs and re tries are also available air steps, but they are provided by the workflow basic steps. Plug in this plugging should already have been installed in your initial set up off Jenkins . Sleep and error steps are also provided by this plug in. There are many others useful steps provided by the workflow basic steps plug in which you you should also explore further. There are two ways you can use retrying time, owes separately or nested. Let's look at how they work separately for retry. You can see that we have indicated a section of court for retrying. We are using ever from workflow basic steps to indicate that an ever were happen inside the retry block and even retry the section of quote a game for three times. Let's run this and see what happens. As you can see, it behaves as we had expected, throwing the ever three times and also the after retry statement wasn't printed out and a beauty ended in failure. Now let's take a look at timeouts here. You can see that we're indicating a time off one second. But in the time out, block off court, we cause the script asleep for two seconds. You can also specify other units of time here, like days I was s that draw. The sleep step is also from the workflow basic steps Plug in. Now let's run this and see what happens. As you can see, the script goes to sleep and times out and the beauty drop is aborted. Now let's see a nested example. - So what we're trying to do here is to cause a time out for three times. And as usual, we have to sleep step, causing the time out. Let's run this and see what happens. So let's go and see the time what happened once, twice and three times and a butte drop was aborted. I hope you find is useful. And now let's move on to the next lecture 7. Declarative: Pipeline > Tools: in this lecture, we're going to take a look at the two section. We can add a two section under stage or under pipeline. We have already shown steps and agent, so we shall skip them. So what a two section does is to refer to pre install tools under Global to configuration in Managed Jenkins and makes them available for use in the pipeline script. Megan is already installed on our Jenkins silver, so less at that in global tools configuration. - Let's now create a pipeline job in here. We can see that we have assets step. It belongs to the notes and processes plugging that is already in store. In Jenkins, What he does is just to execute a shell script. And in our example, it prints out the me even version. You can off course at other tools, like another version of Jerry K or Greater Oh, etcetera. You just need to reconfigure them in global tools configuration. Let's see if the job and run it. As you can see, maybe Inversion is 352 And maybe home is user Sham. Even I hope this example helps you understand what the two section is for and how to use it . Let's move on to the next lecture 8. Declarative: Pipeline > Stage > Options > Error/Retry: In this lecture, we will be looking at the Error step and options directive, specifically the retry step options and also, very briefly, the script step. The script step provides us the ability to write custom court custom groovy coat beyond what the decorated Syntex allows us to do. We will explore further the script, step in a later chapter. So what does The ever step do indicates that ever in the current stage and Prince on every message, you know example, we will be using it together with the options retry step to demonstrate how he works. So let's create a pipeline job before we save it. Run the job. Let me just explain what is going on. So in this example, we have said the options under stage to retry three times in the stitch feels so under steps. We have printed a few eco statements and used the ever step to indicate an error, which will cause the stage to feel and fast. The script will retry to stage again, however, also note that the after error statement will not be printed out as the script well built at the error step and retry the stitch again So let's save and run the job. So from the console output, you can see that the before error statement and error statements are printed out three times before the Butte eventually feels please. Also note that by setting the bill results of failure within the stage, it does not make the script re trying to stitch again. Let's modify the script to see what happens. What the script does is to use the current built variable, which represents the current built and set the result to failure. The current's built variable is one of the many others made available by Jenkins to our pipeline script. We will cover these variables and later chapter Let's run the script again. So as you can see, the butte has filled. But there's no retry. Now let's go ahead and move on to the next lecture 9. Declarative: Pipeline > Stage > Options > Timeout: in this lecture, we take a look at the options time out. Step steps in the options directive are invoked before entering the agent or checking any wen conditions, which we will cover in another chapter. With this step, we can specify a waiting period before the steps section is executed. Let's take a look. Looking at the example script. We have set the time out to be one second other very values on nanoseconds, microseconds and so forth. As you can see, we have used a sleep step from the workflow basic steps plugging to make the script sleep for two seconds. This will cost the stage to time out, less safe and run the job. The script waits for the time out, echoing, Hello World Sleep for two seconds and any times out I hope you find is useful. Now let's go ahead and move on to the next lecture 10. Declarative: Pipeline > Stage > Options > Timestamps: in this lecture, we will show you how to time stand yet console output. I will combine the demonstration for both states. Level in pipeline level as they're essentially the same. Let's create the pipeline job. As you can see, we have times them option under the stage built, but we have none full the test ege. So the expectation is that we should be seeing the time stem printed out before the echo lines for the build stage, but not for the test ish Let's run the job. There you go. Now let's change it to be at the pipeline level so as concede the time stem step is best fight at the pipeline level. So the expectation is that we should be able to see times them being printed out for every echo line. And there you go. We see the times then been printed out for the entire script. I hope this was helpful. Let's move on to the next lecture 11. Declarative: Pipeline > Stage >Options > Timestamps (alternative method): in this lecture, we could look at an issue that some students my face with. The time stems inside the options section, as demonstrated in the previous lecture. Sometimes we might encounter in a row invalid option type time stamps. As described in this juror issue, I've given the link to this jury issue as a resource under this lecture. No, when you when you get this error, one walk around is to use the times, then block instead of using it inside the options block. Now let's create a job to see what that looks like. - Now , here we specify at the stitch level or time Stems Block, which must recite inside the steps block, know that we are not using the options block at all that's safe and run the job. Now, as you can see from the console output we get, the same result at as the previous lecture where we specify the time stems as an option At the state level. However, this alternative method will not work at a pipeline level, as you will get a syntax error so going back to the configuration page. So this means that you can't put you can put time stamps, Um, over here or even at the pipeline level. You can't do that, right? You get a Syntex era. Okay, so I hope you find is useful. Let's move on to the next lecture. 12. Declarative: Pipeline > Stage > Options > SkipDefaultCheckout: In this lecture, we will be demonstrating on how to use Skip default checker on the stage and also under pipeline options as they walk in similar ways. What this option does is to prevent the build from checking out source code from the repository automatically. Let's take a look at an example, so we will be making use off. Get habits, attest repository. And it's such we will need to create get up credentials and Jenkins. - Now let's take a look at what is in the repository. So we have a Jenkins file, which contains our pipeline declarative script and also a text file court normal dot tex. So in here were specified agent to be none at a pipeline level. This is important as we do not want the script. Check out the court in the repository at department level. We want to control that at a state level. So we're specified agents as any and the skip the fore checker option at the state level. This is just a normal tax. We've We've a number in here where we will be incriminating the number as we make changes to the Jenkins script so that we can see the effect off with and without the skip before check option. Now we create a multi pipeline job. We will not be creating a normal pipeline job as want to make use off the Bill configuration section, which will allow us to specify the location off the Jenkins found in the repository. - This is the bill configuration section, and this is where we specify the path of the Jenkins, fall less safe and run the job. As you can see, the multi brunch pipeline, John is able to locate the Jenkins Fall on the master brunch. So, as you can see from the console output, we have not Bean checking out any court from the reports a tree. Let's go to the pipeline steps and check the workspace and there's no workspace. It doesn't exist. So let's now un comment out the skip default check out. That's no rebuke the job. So as you can see, the script checks out the foul in the repository under the stage built and prints out Hello World. Let's take a look at the workspace and there you go. We have the Jenkins fall and a normal dot text foul. Let's now increment the number in the text field and an able skip default. Check out. Let's see what happens. - Let's not rebuild the job. Okay, so nothing is being checked out. Let's go to pipeline steps, and it's can see the Texas to one that's not disables. Keep the fore checker and re commit the Jenkins script. - Let's not rebuild the job, right? The push. I wasn't successful. Let's not run the job again. So as you can see, the court is being checked out and let's check out the workspace and the number has been updated. So let's not change the agent at a pipeline level to any on comments. Out. Skip Default. Checco. An update, a number in normal dot tex Let's now rerun the job. So as you can see when agent is set toe any a problem level. Skip the Fore Checker option. It's dish level has no effect unless we specify options at a pipeline level, which I will demonstrate Knicks. We're committing the fall, and now let's rebuild the job. So, as you can see, no court is being checked out. I hope you find is useful. And now let's move on to the next lecture 13. Declarative: Pipeline > Stage > Environment Credentials: In this lecture, we will be covering the environment directive at the pipeline and stage level. These are not global. There was provided by Jenkins, but our environment variables specify in the script. We will also be covering the credentials method in the environment directive. So let's take a look at a simple example. So what we have here is we specified to environment variables, name one and named, too, and add a Stich level named three, and we print them out using the echo step from the workflow basic steps plug in. We can see that the environment variables specify at a pipeline level, I says both throughout the script, and thus we can use them in the stage section. Let's run the jump and see what happens. All three named Variables are printed out. Let's not put in a new stage court test, and we try printing out the same variables that's safe and run the job. So, as you can see, name three is only available in stage, built by not in stage tests. So we encounter an error, but we have no issues printing out Nate. More name one and name, too in stage test. Let's not try a difference in novel, where we specify an environment variable at a stage level that has the same name as an environment variable at a popular level, we can now see that we have additional name to variable at the stage level. Let's see which one gets printed out. Let's run the job. We can see that might gets printed out instead of John. From here, we can tell that the environment variable at the stage level takes proceedings over the one at pipeline level. It is also useful to know that the environment variables are also made available to scripts . If you ever need to use them, let's see an example. We have a shell step here from work floor, durable car step plugging, which helps us to execute shell scripts or commands. We will be using print envy to print out the environment variables. Let's run the job and see what happens. So that's such for name one in the environment variables named to name and named three. So as you can see, all three name variables are all made available to the shell, so let's move on to the credentials method. This method here allows us to retrieve credentials previously created in Jenkins and referred to by his i. D. Let's create some dummy credentials. You will now create credentials, off type, user name and password. We were now and and other credentials off secret texts. Credentials. Off type secret fouls are handled in exactly the same manner as secret tax, so we won't be showing that here. So with this example, we will try to access the credentials vier their i d and printing them out. I know that for user name and password credentials, we can access both the using impossible using some user name and password variable in the form it off. Use the name colon. Possible it. But if you want to access the using impossible individually, you can use variables like some using him password under school U S. R and some using possible it P S W. Let's run the job and see how he behaves. We can see the print lines for some using password and some secret variables, but they all prints out multiple s tricks. This is done by Jenkins to prevent revealing what the credentials are. I hope that this has been useful and let's move on to the next lecture 14. Declarative: Pipeline > Stage > When (Part 1): in this lecture, we will be covering the wind directive. The conditions in the wind directive determines of the stage should be executed. It must contain at least one condition. If there are multiple conditions, all of the conditions must return. True for the stage to execute, let's take look at the environment petition with this example. We have a deploy to environment variable, and we're set the wen condition to specify that the environment variable deploy to has to be or value production before the stage can be executed. Let's run the job so you can see the Echo State money sprinting out deploying, so we know that this dish is indeed executed. So now let's change the value of deploy to do something else and see the state's runs so as you can see the state Schwartz not executed. Now let's take look at the equals condition. - So we have an environment variable called some name that is a sign of value off Jeff and the equals condition is expecting Jeff for the stage to execute. Let's run the job so we can see that Jeff is being printed out, so the stage is indeed executed. So let's set the value off some name environment variable to something else and rerun the job. So that said it to John. And we're expecting that equals to evaluate force. Let's see what happens. So the equals condition is not fulfilled. Thus the stations don't executed. Let's take look at the not condition. - We are reusing the previous example and nesting the equals condition. Insight, the not condition. Let's change the name off some name to John. Let's run the job and see what happens. So the crews evaluation is returning false because we have John as the environment variable and we are expecting the equals conditioning, suspecting Jeff. But however, the not condition inverts the true value, so that's why the state she's executed. That's no set, the variable named environment Variable name to Jeff so that we're expecting this equals condition to evaluate the true and then that gets inverted about it. Not, and we're expecting that the stitch is not executed. Let's see what happens. And yes, the bill is skipped. So now let's take look at the expression condition. The expression condition allows us to specify groovy expressions and evaluates them. Let's see an example. - So here we specify a groovy expression and equals condition for an environment variable coat version. So he's expecting version to be 1.0, and this equals condition to be evaluated. True. So let's save the job and see what happens so we can see that the stage is executed. Now let's change the value of version 22 point through and run the job. As expected, the stage dust on execute now elastic look, it's the all off condition. - So what? This condition dust is basically requiring all conditions in it to evaluate to true. So we have to environment variables here, version and some name. So both me to evaluate to 1.0 and Jeff for the stage to execute. Let's see things. Let's let's run the job and see what happens. And we can see that the say she's executed. So now let's change the value off version to 2.0 and rerun the job. We're expecting the stage to not be executed. And yes, the station skipped. Now let's take look at the any off condition, - so reusing the all off example we have not replaced all off with any off. This condition requires that any of the conditions in it to return. True for the stage to execute know that the version is set to 2.0, so that evaluates to false. But we are still expecting the state to execute some name. Really, Valerie to true. That saved the job and running. And yes, the stage executes. Now let's set the value off some name to John so that this condition will evaluate to false and expecting the states. Do not execute. Let's see what happens. And yes, the stage was not executed. I hope you have found is useful. Let's now move on to the next lecture. 15. Declarative: Pipeline > Stage > When (Part 2) > Branch: in this lecture, we continue to take a look at the other wind conditions. Let's continue with the branch condition. So the brush condition specifies that the states will excuse only when the bill is building a certain brunch and get up. We already have a repository for this example where we have a single brunch master and a single Jenkins fall. This is the syntax for a brunch condition inside the wind. Direct. If we see that we have two stages here, one for master and the other for death issue states will execute depending on which branches being worked on by the job. There's no create another death brunch that's not create a bill job. We will be creating a multi branch pipeline job choosing get up as a source that save it and we can see that the multi brunch part line job has stepped into two branches and abusing them. Let's see what a console prints out for master. So from the output, we can see that only the master stations executed and a deaf stitch will skipped. Let's see the deaf mute John he should be the opposite built monster skipped beauty in death. I hope you find this useful. Let's move on to the next lecture 16. Declarative: Pipeline > Stage > When (Part 2) > BuildingTag and Tag: in this lecture, we take a look at the building tech and tech conditions. They're related to each other. The beauty intact condition only allows the stage to execute when we are building from attack. The tech condition only allows a stage to execute when we are building from a specific tech or tech name that fits a particular pattern. Let's take a look at the building tech condition first and get up. We already have a repository half a single that has a single branch master and a single Jenkins fall. So in here were specified that the state should only execute when we are building from attack. Let's not create the beauty job selecting the multi branch pipeline job, and we're selecting the get hobbits on source. Know that we have. We have to add in a new behavior Discover, Tex or the text that we create will not be picked up by Jenkins. Let's save the job so we can see that the muscle brush is picked up by Jenkins. Now let's take the master brunch. Okay, so we're now in the master brunch. Let's take it to be 1.0, and that's push it, too. get up. Okay, so when we go back to get hot under the release section, we can see that 1.0 is created. Okay, let's go back to Jenkins and scan the repository. We can see that, Yes. Picked up the 1.0 tech, and at the same time, you can see that there's a text tap here and we've got one tech right here. So let's do a built for the tech so we can see that the States was executed. Now, let's do a beautiful master so we can see that the States will skipped because we're not building from a tag. Now, let's mortify the Jenkins fall to use the tag condition. Let's replace the building tech with Tech 2.0 and let's commit the foul to the repository. Okay, so we're gonna take 2.0 and push it to get up. Okay, so now when we refresh this page, we see 2.0 at 1.0 tax, right? So they're both pointing to different commits. So what we're gonna do now is to remove the elites a tent 1.0, and we're gonna move it right to point to the same Commit s 2.0. Okay, so that's been deleted. And we're going to Tech 1.0, okay? And we're gonna push it to get up. Okay, So when that now, let's refresh the page. And you can see that both tech 1.2 points irritable, pointing to the same committee, right? So that we're doing this so that when we built the 1.0 tag, it picks up the latest Jenkins fall and not the one that was previously tagged 1.0. So now let's go back to Jenkins and do a scan of the report again. Okay? So tech 2.0 was picked up, and you can see that accounts for the text tip has changed. So let's do a built for tech 1.0. Okay? So you can see that the States will skipped because we're only building for tech 2.0. So let's go to tech 2.0 and to a bill, and we can see that the station was executed. Okay, so now let's modify the Jenkins fall to use a pattern in attack condition. So I'm gonna replace Tech 2.2 tech release Desh stock. All right, so I'm gonna commit this to to the repository, and I'm gonna take this right tech. This is released to prod, and I'm gonna be pushing it to get up. Okay, so let's take a look at the release page, and yet we can see that released approach has been uploaded to get up. Okay, so what we gonna do next is to move the tax 2.0. So first, bigger, delete it from get up, and we're gonna take it again, and we're gonna push it. Okay, so that's refresh. Get up. Speech and tech 2.0 and tech released approach You point to the same comet. Right? Okay, Now let's go back to Jenkins. Scan the repository. Okay, So the release to protect was picked up, and the count has changed. 2 to 3. Okay, so let's do a built for 2.0. So the stitch wore skipped as expected. Now let's do a built for release to pro, and the stage was executed. Now for the tech condition. There are other attributes that you might want to explore. I would encourage you to try them out like Comparator and and a different values for Comparator, I hope you find is useful. Let's move on to the next lecture. 17. Declarative: Pipeline > Stage > When (Part 2) > Changelog: in this lecture, we took a look at the change lot condition. The change lot condition only allows the stage to execute when the commit message for commute full feels a certain regular expression and get up. We already have a repository for this example where we have a single branch master, a single Jenkins foul and a normal dot tanks. So we have specified that the stick should only execute when they commit message. Contains a message that fits this regular expression. The normal dot text file contains some dummy tex. It is there for us to modify so that we can commit changes to the repository. Let's not create a beauty job. Selecting a multi brunch pipeline job getting a get hot sauce. We can see that they're multi brunch. Pipeline Job has detected the master brunch. Let's see what a consul prince out for master, it says, warning. Empty change law. Probably because this is the first built that's not modifying the normal dot text foul, and as we commit, we were used. A message, therefore, fears the change. Long regular expression. Let's rerun the job. So from the console, we see that a comet message meets the regular expression and the states gets executed. Let's not make some changes to normal dot texts and putting a comet message that does not meet the regular expression. - We running the job, and from the console, you can see that the states were skipped, I hope you find is useful as move onto the next lecture. 18. Declarative: Pipeline > Stage > When (Part 2) > ChangeRequest: in this lecture, we take a look at the change request condition. The change request condition only allows the States to ask you when it is a pool request and get up. We already have a repository for this example where we have a single branch master, a single Jenkins fall and a normal dot tex. So we are specified that the stage should only execute when there's a pool request in the Jenkins fall in the normal dot text foul. It just contains some dummy text. It is there for us to modify so that we can commit changes to the repository That's not create the bill job, selecting a multi branch, part line job, selecting the getting up source and saving it so we can see that the, um, the master branches is being detected. So now let's create a new depth brunch. So going back to the DOS console, you do get fetch and changing the brunch. It's here diff. Okay, so now we are in the death crunch, so that's more defined. Normal dot Tex. So that's changes to to saving it, committing it to the death brunch. Let's refresh the page. Okay, so the normal dot text file has been updated. Okay, so that's skin the repository. Now we should see the death brunch. Okay, There you go. Now that's some Eat a pool request creating a new pull request. Let's go back to Jenkins and scan the repository so we can see that there is a pool request going back to the main page again. Now we can see that there's a new pool request. Just ignore the ah number. NPR eighths is usually starts at one, but I've done the food if you pull request before, so just just ignore that. So, as you can see, the pull request has a really already been built. Let's take a look at the console and you can see that the stitch was executed. Now let's go back to get up much to pull. Request conforming too much. Scan the repository again. You can see that the death brushes disappeared when there was a pool request and let's go back again and the death brunch appears again. So let's let's look it master. So when there was ah PR merch, Master Waas was being Butte. But let's do a fresh butte now. Let's take a look at a console. You can see that states will skipped right because it's not a pull request now for the change requests option. You can see that from the documentation. There are other parameters other attributes that we can play around with, Right? So let's let's take a look at a simple example using title, I would encourage you to try out the other options. So let's go back to DOS. Get brunch. So we are deaf. That's update the Jenkins fall. Okay, so that's modified A change request to only execute the stage when the title is when Desh pr. Let's commit the new changes in. Okay, so the court has changed has been submitted. Okay, so what? We're now gonna put in a new pool request. Now, take note that the title off the pull request is pipeline desh change requests. Right. So that's that's created pulled quest here. Okay, let's go back to Jenkins and do a scan again off the re pool. Okay. So we can see that a poor request was detected. Let's go back to the main page and we've got a pool quest one here, so p r. Nine and let's take a look at the console for PR nine and the stage was skipped, right? So that was there was expected. Let's merge the pull request. I'm forming the merch and let's do a scan off the report. Gin. Okay, so everything looks good. Death Brown shows up in Jenkins again. Now let's modify the normal dot tax. Okay, it's changed a text here saving it, committing the changes to death brunch again, and we are pushing it to the death brunch going back to get up. Let's create a new pull request. Now take note that we are changing the title of the request to when Desh pr right? Okay, let's go back to Jenkins to scandal Repository. One pull request was picked up that school back in day. Let's forget a consul PR 10 and that you can see the stitch was executed. I hope you find is useful. Let's move on to the next lecture 19. Declarative: Pipeline > Stage > When (Part 2) > Changeset: in this lecture we take a look at the change set condition. The change set condition only allows the stage to execute when the fouls that were committed has foul names that made a certain regular expression in get up. We already have a repository for this example where we have a single Jenkins fall Ah, hello. Whoa! Got jets and a normal doc text foul. So we have specified that the stage show only execute when the commit the fouls have found names that fit this regular expression. So basically, we're looking for just JavaScript falls Both the hollow world RGs and normal dot text files contain just dummy Tex. It is there for us to modify so that we can commit changes to the repository That's not create the Butte job selecting multi branch pipeline specifying that get up source and saving the job so we can see that the master branch has been detected. Let's see what the consul prints out for the master brunch. So it stays here warning. Empty changed that probably because this is the first build that's not modify the hollow world out gs foul saving it for meeting the changes to the repository running the job begin. So now we see that the committed found names meet the regular expression and the stage gets executed. That's not make some changes to normal, dot tex and committed. Let's rewind the job begin and we can see that the stitch gets skipped. Note also that you can also specify case sensitivity using this case sensitive field, and we'll set it to true. So I'm modifying the Jenkins Fall and changing the regular expression to look for found names that end with upper cased World and the extension to B. J s that's also updated the hello world dot Js file. Let's commit the fouls to report a tree. Let's not rerun the job, and from the console, you can see that the states was skipped. I hope you find this useful. Let's move on to the next lecture 20. Declarative: Pipeline > Stage > When (Part 3) > BeforeAgent: in this lecture, we take a look at the before agents condition by default. The before agent is set to false, which means that the script were execute the when directive on the remote agent, assuming there is one, regardless of whether the Wind directive is gonna return. True or not, however, when the when the before agent is set to true the when directive will be Valerie to first and if the window active because true, only then would agent be entered to execute the stage. Let's take a look at an example. So for this were set up the remote agent to be slave one, which is viewable and the managed Jenkins manage notes, sleep one year. So let's create our Jenkins job. Take note that for this example, we have set the agent to none at a pipeline level. But at a stitch level, we have set the agent to slave one. Take note also that when that when directive where it's unfolds due to effect that the deploy to environment Vero is set to death. But we're checking for production. So we are expecting that the script were X Q on slave one as the before agent is said to force, Let's run the drop in cedar output. So ask and see is running on slave one and the stage was skipped. Now let's go back and change that before agent to True, That's rerun the job. Now you can see that slave One agent was not called and the stage was skipped in. Master, I hope you find is useful. Let's move on to the next lecture. 21. Declarative: Pipeline > Stage > Parallel/FailFast: in this lecture, we were recovering the peril Block under stage section, which is useful if you want to run stages in peril. If there are no dependencies between them, we will also take a look at the fail fast option. Let's see a simple example. So here we have a stage that contains apparel Block that they're also contains other stages indicating that all these stages are to be run in peril. Okay, so the feel fast key word being set to true indicates that she, one of the stages fail. The rest of the stages should also feel so. Each stage is set to sleep for 10 seconds and let's run the drop to see it in action so all the stages are running in peril. Let's change the script to get the stages to run in sequence to see the difference. So here we do not have master stages, and each stitch sleeps also for 10 seconds. Let's run the job so the job runs significantly slower as the stages execute sequentially. So now let's change the script to see how fail fast works. So the script is pretty much the same as the first example, which is the peril example. But for Stage two, we have set the sleep timer to be two seconds as compared to 10 seconds for the other stages, and after that it throws an error. So let's run the job to see what happens. So, as you can see, all three stages are executing at the same time. After two seconds, Stage two filled and that resulted in Stage one and Stage three feeling. I hope this has been useful. Let's move on to the next lecture. 22. Declarative: Pipeline > Stage > Input: In this lecture, we will be covering the import step under stage section, which is useful if you want to allow user input, which will affect the built floor. It is important to highlight that the states will pause after any options have been applied and before entering the stage agent or evaluating is when condition. If the input is approved, the stage for then continue. Any permits is provided as part of impulse submission will be available in the environment for the rest of the stage. Let's see a simple example. Here we have the input step with the message option, which allows us to specify a high level message for the input. Next, we have the okay option where we can specify the text of the okay button. Next, we have the summit, the option here where we can specify users or groups that are allowed to some meat, the user input for creating users. They are found under managed Jenkins. Under manage users for groups, you can get Jenkins to connect to held up or active directory. But for the sake of simplicity, we were just used users. Let's create a dummy user now I'm carrying currently locked in S f mean at local whole stock calm when you specify to something for value used, the user i d value, which is this one here dummy user and at mean at local host dot com Know that the Summit er is an option off field. So when we omit this option, it allows any user to submit the user input. We can also specify multiple user ID's or group names by the D limiter comma. Please be aware that you must remove all white spaces between the I DS. So if you can figure dummy user comma at meaning locals dot com do not leave a space in between dummy user and M in at local host dot com. Except for the comma, we will show an example later. Next we have the summits, a parameter where we can specify an environment variable that contains the summit is I D. Is specified. This is the name of the return value. They will contain the idea of the user that approves this input as an example use case. The value can then be used to print out on the console, from which we can tell who approved the build. Next, we have the perimeter option where we can specify the import controls that a user can interact with. Commonly used options for the frank for operators are these ones here? We can provide a single text field using string. We can provide a tick box button a tick box using Boolean Param, a drop down list using choice. I know that you have to use New Line characters to separate the different options in the list. A text area using texts, a passport field using password, a foul selector using foul and the credentials Drop down. This how we reference the variables. The values in the user input is by using the dollar sign. Breck. It bearable as shown over a year. Let's run the example and see how it looks like. So I've copied over the script for comparison purposes. So let's stick Look, so we've got We've got the environment here and we've got a default value Death. We've got a version tax for you here. Default value 1.0. We've got the tick box for bullion. Param, we've got the drop down This for choice for for AWS, for region. We got a text text area here. If God's the password field and we've got a false Lecter here and we've got a credentials drop down list, so let's look OK and see what happens. So as you can see, we're printing out the input values and, as you can cease Emina locals, it is actually referring to Is that you referred to by Who is some meter, which is specified as a submits a parameter. Another thing that you might want to know is that there is another way you can keep your input without going to the console. Let's do another built to show you what I mean. So when you click over here and not a pop up will appear, which provides you a link to Kenya input, let's go back to the script again. So let's look at what happens when we specify a space here. Let's run the job again and you get an error because of the white space. I hope this has been useful, and let's move on to the next lecture 23. Declarative: Pipeline > Stage > Post: in this lecture, recover the post section where there are steps that run depending on what condition the station beauty is in. Take note that a poor section can appear at the end of a stage or at the end off the pipeline. The post condition blocks are these ones here, and remember that execution of the steps are in this particular order. I will show you examples of the post section at a popping level, as it also works the same way at the state level. Let's see an example. So in this example, we will demonstrate three post conditions at one goal. Success, failure and always, success only runs if the current pipeline or stitch has a success status, and the same goes with failure. The pipeline or stage has a failed status and always blocked. We always run regardless of what the status is. So as you can see, we have commented out the error steps so that a bit will be successful. Let's run the job. Okay, so the beauty successful, the success Post condition is executed. It's always always block. Now let's go back and uncommanded error condition and we run the job. Now the failure block is executed, but not the success. One and always block is always executed. Now let's take a look at the changed condition. So with this example, the change block only runs if the covering bill status or the state status has a different completion stage from the free previous one. Take note that we are using a script block here, so if you're not familiar with the script block, there's a lecture on it. You might want to wash that first and come back to this again. So in this script block, there's a global variable called Currents Built. You can find all global variables that are available to the pipeline under pipelines in Texas and then clicking on the Global Variables Reference link. Let me save the job first and show you where to find this. Some of these variables here I installed by plug ins and not by Jenkins. So if you search for current built, there you go. That's the, um, global variable being used by the script. So we're setting the results off the current butte to be unstable. So let's get the beauty to run so changed. It's cold because the previous Butte wars failure, and now it is successful. Now let's get it to be unstable. - So it's going to see the color now is yellow, so it means that is unstable so I can see that a change block gets executed once again. So as long as the bill or stage status keeps changing from the last one, this boat will still get executed. That's running less running one more time, so the change blocked does not get cold, as the beauty status has not changed from the previous one. Now I will take this opportunity to also demonstrate unstable condition. Let me at in the unstable block, which only runs when the current pipeline of Stitch has an unstable status that's safe and run the job and the unstable block. It's cold now. We look at the fixed condition, so the fixed the fixed block only runs if the current build or stage is successful in previous run filled off or waas unstable. Basically, that means that it runs only when the build is fixed. So as our previous built was unstable, let's run this and see if it gets cold and they go. The fixed block was executed. Let's move on to the regression condition. So the regression block only rancid. The current built or stage cedars is failure, unstable or bought it and previous run waas successful. So this is the opposite off fixed. So the last example was successful and we have set this built to fail using the era step so the regression block should get caught. Let's run the job and expected the regression block wars executed. Let's take a look at their border condition now to get the bill to abort, We are using the same trick as we did with unstable. We set the currents the result of the current built to be aborted and we have their boats. It block here right, which runs only when the current pipeline on states has an aborted status. So let's ah, seven run the job. Okay, so the aborted status is denoted by agree color. Okay, so the aborted block gets executed. Now let's take a look at the cleanup condition. So the cleanup block runs after every other post condition has been evaluated regardless of the status off the built or stage. Now, with this example, we have four post conditions success, failure, always and clean up. Like I mentioned before, the post conditions are always executed in a particular order, starting with always an ending with clean up right is it always gets executed in this order . So I shall toggle between success and failure, and you'll see that, even though always conditioning specified third in the script, it is always executed first and clean up excluded loss. So let's get the beauty to be successful first. So, as expected, always is executed first full of my success and then clean up. Now let's get the butte to feel okay, So that's enabled the aero step and rerunning it. So we have always first full by failure and then clean up. I hope you find is useful. Let's move on to the next lecture. 24. Declarative: Pipeline > Options > BuildDiscarder: in this lecture, we were recovering the options directive at a pipeline level. Take note that some options under this directive is a really covered by the lecture on options at a state level such as retry time out time stamps and skip default. Right, so we won't be covering them here. Let's take a look at the bill. Discard er option. So build this. Carter instructs Jenkins to maintain a number of runs for the job in this example were specified Jenkins to maintain just one single Butte run. Let's run this job. Okay, so the beauty successful. Now let's go back into configure and you can see that there's this new section here, right? That is convenient now. Mex number abuse to keep They're set to one. Let's go back to the main job beach and rerun the job again. Now it's going to see Jenkins will show the previous built runs. But when you click on the console link, you are sure history be 404 Okay, so you gotta keep, you know, refreshing the page. Ah, and you can see that only maintains one bit at a time, right? So that says built one more time, okay? And refresh the page. Okay, so this is when you just want Bute here. Now, let's change the number. Bill runs to keep to say to, Right? Okay, saving it. And this Do the job again. Okay, that's going to console. Okay, so we can still see the locks for built three. And let's beauty it again. All right? And, uh, let's refresh page. Yep. So we can see we can see built four and five. So it only maintains a history of to pass jobs, and that's going to configure. And we can see these value has changed from I wanted to. So I hope you find it's useful. Let's move on to the next lecture. 25. Declarative: Pipeline > Options > DisableConcurrentBuilds: In this lecture, we take a look at the Disable Concurrent Buttes Options of Adoption Directive. What this option does is to disable concurrent built in case you might want to prevent concurrent access to share resources. For example, let's take a look. So what we have here is that we have commented out that this able concurrent bills options option for now, and we also want the built to sleep for 10 seconds using the sleep step. When we run the bill, we're gonna try to build another one so you can see that the beautiful right are running concurrently. Building first job and we're building the 2nd 1 Okay, so we have two jobs running concurrently. Now let's enable the disable concurrent bills option saving and running the job again. So, beauty, the first job and beauty in the 2nd 1 so you can see that the second job becomes pending and it's waiting for the first job to finish. I hope you find is useful. Let's move on to the next lecture 26. Declarative: Pipeline > Options > OverrideIndexTriggers: in this lecture, we took a look at the override index triggers option off the auction directive. So when this option is set to false, you're cause Jenkins not to trigger Bill when new comments are picked up. When set to true Jenkins were triggered builds on new comments. Let's take a look at an example, so we will be making use of a good heart repository that has only just one Jenkins fall in here. We have commented out over right index triggers for the time being, and we have used the time stamp option to print out the time stand for the Hello World Echo Stephen by default. Any comments to any of the guitar branches because a built to run. But this option allows us to customize this behavior based on some condition. But this will probably require scripted pipeline, which involves groovy code. No, their condition might be that you want certain branches development branches, for example to be beauty on new comments but not other branches for some reason, so this over right index triggers option allows you to do that. Let's create a Jenkins job choosing a multi branch part line, choosing a get up source. And we need to check this tick box as we want the Jenkins job to scan a repository every one minute. Now that's safe. The job. So Master Branch gets picked up and a new beauty was done. And you can see that, um, a schedule built for brunch master was done. Now let's set hello, world one to have a woe to and we will set off right index triggers to force committing that. Let's wait for Jenkins to pick up the changes. Okay, so a second built was scheduled, and you can see that hello World to was printed out. Now that's changed the echo statement to print out a hollow wolves to print out. Hello. Whoa. Three committing the changes. And we wait for Jenkins to pick up the new changes. Okay, so Jenkins picked up the new changes. But however, it did not schedule built for brunch, master, because we're set the over index triggers to force. So in order to reverse his behavior, we need to set over indexed, register true, and do a manual butte again. So unless set hello world 3 to 4 and set the over index triggers to true meeting the new changes. Doing a manual build. Hello World Force printed out. So now that set Hello World Four, 25 and call me the new changes. And let's wait for Jenkins to pick up the new changes. Okay, so we can see that a schedule built wars meet for brunch, Master. So Jenkins is scanning the repository now and doing bills I hope you find is useful. Let's move on to the next lecture. 27. Declarative: Pipeline > Options > SkipStagesAfterUnstable: in this lecture, we look at the skip stages after unstable option off the option directive. So what this option allows us to do is to skip downstream stages. Once a stage has caused the bill to be unstable, you might want to do this. When subsequent stages are dependent on the upstream stages to be successful, let's see an example. So we have commented out skip stages after unstable for the time being, and we have two stages here Butte and deploy so in abuse that should have meant use off the currents bill Global variable and said the result. Property of current Built to be unstable. This global variable can be found on the pipelines in text in the Butte job Main page, followed by global variables references and a deploy stage just prints out the echo semen. Let's save the job. So here's the pipeline syntax link. Let's open it up, Clicking on global variables references and doing a search for currents built Let's run the job So the bill is now unstable and both stages got executed. So let's go back to enable that's keep stages after unstable and see how the bill behaves. So the bill is still unstable and the deploy stage was never executed. I hope you find is useful and let's move on to the next lecture. 28. Declarative: Pipeline > Options > CheckoutToSubdirectory: in this lecture, we take a look at the check out to subdirectory. Option off the option directive. This allows us to specify where to check out the CO two in Jenkins. Let's take a look at an example. So we will be making use off a guitar repository that has a Jenkins fall and a text fall. So going going into the Jenkins fall, we have specified the check out to subdirectory to a photo coat. Some stop the i R. So that's a relative path within the workspace off the Jenkins job. So for the text foul, it just contains some takes. So that's created Jenkins job selecting multi branch pipeline job and heading a get up source. Okay. And safe and find a job. Okay, so a built was scheduled for brunch, Master. Okay, let's take a look at the console log. So it's running in this sub some sub d i R directory. And if we go into part line steps, locate north, start going to the workspace, okay? And you will see that the normal foul was checked out and you get some text one. Okay. So I hope you find is useful. That's move onto the next lecture 29. Declarative: Pipeline > Options > NewContainerPerStage: in this lecture, we take a look at the new container per station option off the option directive. What this option does is to enable the stage to run. A new instance of the container is still running the same container across all stages. Let's take a look. So what we have here is that we have specified the doctor image to use in a pipeline level and because we're specified it at apartment level and there no agents at the state level, that will be the image to use across the stages. Okay. And we have also specified the new container per station option. And in each stage, we print out the S details. He was in a kit. Common. Let's saving on the job So you can see from the bill in the Butte stage. Container is being spun up, right, and the US details being printed out. The container is stopped by doctor and removed. And in the deploy states, you can see that a new container is being spun up. Same thing who has details printed out container being stopped and removed. And you can tell that the container I d is in this in the deploy stations different from the one in the build stage. Okay, so now let's try commencing out the the new container person option. Okay? And that's rerun the bill to see what happens. Okay, so you can see that a container is being spun up once, okay? And it's used across the build and deploy stage, and the container is stopped and removed by docker so you can see that the container ideas are all the same throughout the script, so I hope you find is useful. Let's move on to the next lecture. 30. Declarative: Pipeline > Parameters: in this lecture, we will recovering parameters at a pipeline level. This is very similar to the parameters in the impact section of the stage level. Basically permitted. Allow us to select options to control how the bill gets built. Let's see an example. As you can see, we are specifying a text few using string a tick box using Boolean Param, a drop down list using choice. Know that you have to use a new Carisch, a new line character to denote different options. A text area using texts, a password, fuel using password of found selector, using foul and a drop down. This of credentials using credentials know that we also refer to the values off these inputs using the parents object here. Let's run the job. Take note of the built now link. The text will change when we come back to it again. As you can see when we run the bill for very first time, the bill doesn't prompt you for input. But initialize is the bill job according to the perimeters block of the pipeline script, and he ran it with the default values. Now, as you can see, the Texas changed. He has become, but we parameters, so let's click on it. So now when we click on it, it prompts us for the user input. And and that's beautiful. And it prints out the import values. Now, when you go into configure, you realize that you have all these additional parameters here. There came from the party line script. I hope you find this useful and let's move on to the next lecture. 31. Declarative: Pipeline > Pipeline Triggers > Cron: In this lecture, we cover the corner option off the Triggers directive. The Triggers directive allows us to specify how we want the pipeline to be re treated were the Craun Po SCM and upstream options with the crown option. As the name suggests, it helps to create a schedule to run the pipeline using Cron String for Met, starting with the minute our day off month, month and day off week. So we have five specify years. Let's take a look at an example. - So here we are specify a corn expression inside the triggers directive, and I have given out examples of how the crone expression can look like. So for the first example, we have zero minute 1 a.m. second day of the month only in March and every day of the week , less safe and run a job. Okay, how the world is being printed out. Let's go back to configure. Now, when you go back into configure, you'll find a new section built triggers and your CEO crown expression in this text box. Right? So now that stick look at the second example. So the second example starts weaver with each right, which can be interpreted as a random value over a range. So what Jenkins will do is to spread out the execution of the schedule job or scheduled jobs that have the hitch in it over a period of time so that the system will not be overloaded. So in this example, it is instructing Jenkins that we can run the job at a random minute within the 0 to 59 minute wrench whenever the Lord is not so heavy mix. Let's take a look at the former off the hour. Specify here where we use slash in a number, it means that we're executing every interval off that number within a range. So with this example, we're executing every two hours, and for the day of the month, we are specifying first to the third day of the month and for mine, specify here. We have specified running the job only on Jen and much. And for day of week we have specified, choose it to Thursday note. Also that values zero and seven are Saudis. Sorry our Sundays. Alternatively, we can also specify running the job periodically by using aliases such as at daily at yearly at an early so on so forth. And we can also specify time zones using this format here, starting with tea set equals to the time zone I ds, which come from the Java Util time zone class. Right. So the the times was specifying times when we require us to specify this carriage streets and character here as we need the time zone Spitfire to be in the first line off the text field off the built trigger section here. Right? So let me just safe and run the job. Okay? Sorry. Let's let's go back to configure. Okay. So you can see that the text field here, the text area here is has been updated with the time zone information it needs to be on the first line. And this message here shows you what time is gonna execute in whatever time zone the Jenkins Marcelo is running in and also signal off the warning message that Jenkins is advising to use Hitch instead off zero to spread the load. Right. For more information, I would encourage you to check out this page here. So this would have, um this would have information that I've covered before and potentially more with um, with more examples given here on what is doable. I hope you find these useful. Let's move on to the next lecture. 32. Declarative: Pipeline > Pipeline Triggers > PollSCM: in this lecture we covered oppo SCM option off the triggers directive. Poor ECM like Ron, accepts Cron String format to determine how often the porter repository for any changes. For any information on the con string format, please wash across on video. We will be making use off a repository in our example that contains only just a text foul called Normal Doc Tax. And it's used to trigger new builds in the Jenkins job. Okay, so let's now create a job to demonstrate a pool ECM example. So in this example were specified to junk. Instead, we want to pull get hot every minute, every hour, every day, off month, every month and every day off the week. And we are also using the check out step, which will check out the court. And in our case, that will be normal dot tex Here is a documentation for the check out step. So for the checkouts that were specified that class to use, which is get ECM, forget Checco and we also specify the branches to check out from and the repository you're ill. So let's save and run the first Butte. So let's go back into configure again and you will see a new bill trigger section, which has the polling configuration that were specified in our script. I would also like to bring your attention to this link here. Get pulling long where you can see when the reports last port. Okay, so the job actually manages to to pull the ECM to pull Get up. Now let's have bit normal, not texts, and call me to change in. - Okay , So the last time when it was pulled was that 11 or two and it seems like it has picked up the new changes that's refreshed. A peach. Okay, so it put one more time 11 03 and has picked up new changes. Okay, so let's go into built to and going to part line steps, locate, not start into the workspace and thats view normal dot tex and you can see he's got a new changes. So I hope you find this useful. Let's move on to the next lecture 33. Declarative: Pipeline > Pipeline Triggers > Upstream: in this lecture, we take a look at the upstream option off the triggers directive. So one upstream does is that it triggers the current job when any of the upstream jobs that are specified have completed with a certain beauty status. Let's take a look at an example. So here we have the option the upstream option that specifies that this drop is to run with upstream jobs when any off the option jobs are built with a success status. So we've got to drop their job one and job to write. And the available status is are unstable failure not built and aborted. So that's saved this and creating upstream jobs. So drop one doesn't really do much except to echo, um, a statement, that's all. Saving it and creating jobs, too. Same thing with job one doesn't really do much. It just prince l. A statement. Okay, so I'm just gonna open all three jobs in different taps. Okay, Now I'm gonna run jump one, and I'm gonna run job, too, and going back to the main job running this job for the first time and now going back into configure, you can see that there's a new bill trigger section with the configuration were specified in the pipeline script. Okay, so we've only got just one built here. That's, um let's run job one. Okay, so once that is done, you can see that built two of the main job has been kicked off, right? And that's run job, too, so we can see built three is kicked off. Okay, so now let's set job. Want to be unstable? Okay, so that's this change script. And again, we're using the current build global variable. We're seeing the result, or they can't build variable to be unstable. So let's do job one. So it's not unstable, and you can see that No, no new built waas Ah, built for for the mean, mean job. Right? Okay, So now let's let's run job, too. And you can see built four was kicked off. I hope you find these useful. Let's move on to the next lecture 34. Declarative: Pipeline > Agent > Docker > Image: in this lecture, we will be covering the doctor option under the agent directive. So doctor has a number of permits is available. We were do a simple example first, using the image option, and we will assume that you already have doctoring start running alongside Jenkins for this and subsequent. It's examples No, that even daughters. Examples here for Agent Doctor is at a part line level. It also applies the same at a state level. So that's created Jenkins job. So we have specified the image that we want to use from the Default Docker Registry, which is Doctor Hop Toby Maven. An Attack 353 Jerry K. 10 Slim. Once the continent started up, the Butte stage gets executed and we just run the command envy. End SV two Short of me, even version. So that's safe and run the job. So look at the console is not able to find the image locally. So is doing a doctor pool, which pulls the image from the Dr Hubbert Registry, and he does some checks on it and runs and container with that image. And then he goes on to the build stage right and runs a comb online and fiendish V Prince Salt, the Apache maven vision and the container stops. Now, when we run the job again, you'll find that a console output is less verbals because we have already downloaded the same image locally and it's cased and Jenkins doesn't need to download again. I hope you find is useful. Let's move on to the next lecture. 35. Declarative: Pipeline > Agent > Docker > Args: Knicks. What we want to demonstrate is the ops parameter. So what this permitted allows US Jewish descent arguments to a doctor run invocation. So that's created. Jenkins dropped to see how that happens. So we are reusing the same example from before and were specified the arguments to set an environment variable called some envy using the Dash E option. And that Desh e option came from here. Okay, and we have said this some envy option to sorry, the environment variable to death. And in the buttes stage, we equity environment variable. So that's safe and run a job. So from looking at a console, we can see that the command being run inside the container it's printing out the rights value for some envy I hope you find is useful. Let's move on to the next lecture. 36. Declarative: Pipeline > Agent > Docker > AlwaysPull: next. What we want to demonstrate is the always pull perimeter. So as you already know, the maven image that we have been using is already cased locally. So this parameter forces a doctor pool that's created Jenkins job to see how that happens. So we are using the same example from before, and we have set the always pulled to true and as before, in the Butte Stitch, we echoed the environment, variable less safe and find a job. So look at a console. We can see that the doctor pool Common is executed, and he's putting from library maven, and he's checking That image is up to date before using him. So let's now comment out. Always pull and rerun the job and see what happens so I can see no doctor Pool is executed. I hope you find is useful. Let's move on to the next lecture 37. Declarative: Pipeline > Agent > Docker > CustomWorkspace: So when we want to use a custom work space instead of the default one that Jenkins has allocated to us, we can use the custom workspace parameter. Let's create a Jenkins dropped to see how to do that, using the same example from before. And we have specified the custom books based to be volleyed Jenkins workspace my custom workspace, right. Ah. And another thing that you have to make sure is that Jenkins has write access to the directory to create it for you if it doesn't really exist. OK, so that's safe and run the job. So look at a console. We can see that it is running in my custom work space. And you have specified to Docker to use that workspace. Okay, I hope you find is useful. Let's move on to the next lecture. 38. Declarative: Pipeline > Agent > Docker > RegistryUrl/CredentialsId: next, we will be looking at registry your l and Registry credentials. I d We use this parameters when we want to use an image from a private doctor registry such as our own or third party registry. In this example, we will be using the key i old dot website to create a private repository. So, in order to create a private repository and keep your eye all we need to open an account with them and click on the tutorial. Think, and it will show you step by step on how to quit a repository. So let's don't quickly create a test reports tree. I have already a party session open to my Jianqing server, and I'm gonna click on the Tora link and follow the instructions. They So I'm gonna be logging Teoh. He don't. I owe okay. And just copying and pasting Thea. Instruction day copying the container i d entry repository name and copying the command year. Okay, so we're pushing the repository to the key container registry. Okay, so let's go to the repositories. Okay? And we're done. So let's create a Jenkins drop to see how we can connect to it. So as you can see we're specified the image to be this value here. So that comes from if you go on to information. There's a doctor pool command here. So that's the same value as the doctor pool. Ah, come on here. Okay. And we specified the registry to be, kiddo, I o And for the registry credentials. I d um, we have to create the credentials I d in Jenkins. Okay, so under credentials, system, global credentials and at credentials Okay, so we'll use that using impossible it and putting all user name and password. And we will put the, um, the ideas kid out. I all all right and save it now, going back to the Jenkins job in the test stage. Once the container is up and running, we use the print envy command to print out the environment. Variables. That's safety job. Now, before we run the job, we need to remove all keyed up. I all related containers and images because recreated them in the Jenkins master to push them to keep what I owe so otherwise, it's not gonna pull them down during the build. Okay, so that's, um, has go back to go online again and removing all containers and the, um, images. Okay, so, um, you can see that he has actually deletes it. The kiddo, I all images, right? Just just ignore the the error messages. Here they are related to our example. So now we can run the job. So look at a console. You can see that it's pulling down the image from the from kiddo I o right, and running it. And the print envy Common is executed. I hope you find is useful. Let's move on to the next lecture. 39. Declarative: Pipeline > Agent > Docker > Label: next, we'll be looking at the label parameter. This parameter allows us to specify wish. Know what? We want to execute the stage with the given container. So we already have a muscle slave set up in Jenkins. Under manage Jenkins manage notes, and the slave is called slave One. Okay, so let's create a Jenkins job to see. I'll see how it works. So we are using the same maven images before, and we have specified the label to be slave one, so they runs the stage enslave one. And as before, we run the maven DSV command in the container to pronounce them even version. Okay, so that's safe and run the job. Okay, so I can see is running on slave one and downloading the maven image. Okay, verifying it and printing out the, um I'm even version. Okay, I hope you find is useful. Let's move on to the next lecture. 40. Declarative: Pipeline > Agent > Docker > ReuseNode: next, we will be looking at the reused north perimeter. I know that this parameter can only be used on an agent for individual stage. It allows us to specify whether to run the container on the agents at a top level of the pipeline on a new note. So with this example, we have two slaves. So if you could manage Jenkins and manage notes, we see that we are slave one and slave to here. So let's credit Jenkins job to see how the reused north perimeter works. So if this creep were specified, slave one at a pipeline level and in the build stage, we won the stage to run the container in slave to and in the deploy stage, we have set the reuse note to true. So issue excuse the stage to run a container in slave one that's even want the job. So going by the console, we can see that the script is running and slave one and the build stages running on slave to as expected. Okay, So staged, um, stage debut stations sprinting out the maven version or good day. And as you can see, we are running the deploy stage here. Right? It's enslave one. Okay, so it's printing out this, um, message here. The indicates there were anyone still in slave one. All right, and excuse the print. E N V. Come on. Okay, so down. Let's set the reuse note to force and see what happens. Okay? Rerunning the job. Okay, so running the screaming sleeve one running the Butte station slave to and they go. So now the deploy stations running slave to as we have no specified wish agent to run it on , it continues to run a slave to I hope you find us useful. Let's move on to the next lecture. 41. Declarative: Pipeline > Agent > Dockerfile: in this lecture, we will be covering the doctor Far Permanente Off agent. So basically, this parameter indicates we are using docker file to run a container to execute a station pipeline. We take a look at the pelline option first. If we set this permitted to be true. You look for a doctor foul in the directory off the build workspace. We won't be covering label arcs and reuse note as they are already covered by the doctor perimeter videos. So let's declared a simple example that includes the use of a get have reports tree which contains our doctor fall. So this is the get out repository and this is our doctor Fall, which includes an instruction to build from the you bunch of latest image. That's all. So let's create a junkie's job. So with this pipeline script, we are setting agents as none year and setting agent to any in the check out stage. And we're using the checkup step from the ECM plug in ECM Step plug in okay. And we're using the check out step to check out form the git repository and loading the, um, Dr Far into the built workspace. Okay. And in the built states were setting the doctor foul to be true, which will instruct Jenkins to look for Dr following the workspace. And then we run the cat Command to bring out the OS details. So that's safe and run the job and see what happens. So it's running on Jenkins in this workspace. Okay, so he's checking out the foul, the doctor foul, and it's building it from you want to laters. And it's running up the container, printing out the operating system details and stopping the container and removing it so I hope you find is useful. Let's move on to the next lecture. 42. Declarative: Pipeline > Agent > Dockerfile > Dir: in this lecture, we will be looking at the de ir option off the doctor file parameter. This option allows us to specify the location off the doctor foul if it's not already at the root off the workspace. So let's take a look at an example. So we will be using this guitar repository and we have created a directory where we have put in our doctor fall. So same as before is during off a you bunch of latest image. So that's creates the Jenkins job. So with this pipeline script, we are setting agent to be none an apartment level and setting agent to any in the check out stage. And we are using the Checker SCM Ah, step from here and, uh, to check up from the repository that was shown earlier. And in the build stitch, we have specified the doctor foul. Toby in. The doctor found the i R directory. So they're instructs Jenkins to look for, you know, the doctor far in this directory, in the workspace. And then we run the cat command to print out the West details so that safe and run a job and see what happens. Okay, so running in the, um, the works based pipeline agent found there are workspace checks out the repository, and you can see that it's managed to pick up the doctor. Fall a toucan. See from here as you specified, DACA files located in this directory here. So it's mentioned. Picked it up, built the image, run the container and prints out the the operating system. He kills and stops it and removes the container. So I hope you find is useful. That's move onto the next lecture. 43. Declarative: Pipeline > Agent > Dockerfile > Filename: in this lecture, we will be looking at the foul name option off the doctor file parameter. So these option allows us to specify the doctor foul if his name is not spelt the default doctor foul with a Capital D. So let's take a look at an example, so we'll be making use off the guitar repository. And we have named our doctor found to be my custom name Doc a foul, which is, as before, a bills from the U Bahn tree latest image. So let's create a Jenkins job now. So with this pipeline script, we've said the agent to none at a popular level, and we set the agent to any in the checkouts teach, and we're using the check out step from the same step Plug in to check out from the repository that we mentioned before and in the Doctor Foul Stitch. We have specified the foul name to be my custom named Dr Fall, and after that we run the cat Command to print out the US details. So let's save and run the job to see what happens. Okay, so is checking out the repository running in this workspace in the bill job books Base picked up the Dr Fall They go. So is building it from my custom named Dr Fall. And he was running up the container and printing out the US details and stopping and removing the container so I hope you find is useful. Let's move on to the next lecture. 44. Declarative: Pipeline > Agent > Dockerfile > AdditionalBuildArgs: in this lecture, we will be looking at the additional build arcs option off the doctor far parameter. This option allows us to specify additional parameters to the doctor billed command. Let's take a look at an example. So we're making use off. Get out, Repository. We've used this reports true before, so we're just We're using it for for this example. And as before, we're just building it from the latest you bunch of latest image. Okay, so let's create a Jenkins job. Okay? So with this script, we've set the agent as none at a popular level and agents as any in the check out stage we're using. Check out step from the SCM step Duggan. This one here to check up from the repository that we mentioned earlier and in the doctor follow states. We specified the additional built arks, which is to tech the image as my doctor. Fall cold an example, right. And then we print out the US details, so let's save and run the job and see what happens. Okay, so is running Jenkins in the build workspace checking out from the repository. And there you go. It's the This is the additional arguments that were specified in our pipeline script. Toothy DACA build command and it's tagging it as my doctor file called an example. Running the image, printing out the operating system details and stopping and removing the container so I hope you find is useful. Let's move on to the next lecture. 45. Declarative: Pipeline > Agent > Dockerfile > CustomWorkspace: in this lecture, we will be looking at a custom workspace option off the doctor. Far perimeter. This option allows us to specify a different workspace location to build and run out docker container. But in our example, for the sake of simplicity were specified a custom work space to be a subdirectory off the build workspace. So let's take look at an example. So we'll be using this kind of repository that we've used before. And we've got a docker file here that builds from the U Bahn to latest image. Okay, so that's created Jenkins job. So with this part lang script, we're setting the agent as none here at the public level and setting agent to any in the check on stage. And we are using the check out step to check out from the get out repository. And this check out step is from the SCM step plug in. Okay, So take note off the extensions parameter here that tells the check out step to check out a repository to this check out directory within the build workspace, which is the same as what we were specifying s the custom workspace for Docker in the Doctor found stage. Okay. And after that, the script Princess, the OS details. So that's safe and run the job. So the script is running in the butte workspace, and the doctor follow is being checked out in a Butte book space. Okay. And you can see that the workspaces in specified as the check out dark tree. And that's the director that Docker is walking in. So it is, yes. Suspecting the doctor foul to be in this directory. Right? So it's manage. It managed to pick it up, so built the image, runs the container, prints out the US details and he stops and removes the container. So I hope you find is useful. Let's move on to the next lecture. 46. Declarative: Groovy Script Outside of Declarative Pipeline Script: in this lecture, we will Delph mawr into the advanced usage off Jenkins Pipeline is court where we will make use off more groovy. Let's take look at an example. So in case you didn't know, you can actually have groovy court outside your pipeline script. So what we have here is we have defined a variable caught name of person and a function cold prince name, which accepts the name parameter and prints it out using the echo step. So in our pattern script, we are making use off the script directive to call the groovy function and use the groovy variable that's run and see what happens so we can see that the function is cold and the name is printed out. I hope you find this useful. Let's move on to our next lecture. 47. Declarative: Global Libraries: In this lecture, we take a look at how we can make use of global share libraries. Global shared libraries are used for when we want to have multiple Jenkins scripts. Making use of common chord or courted does sensitive things that you do not want in the Jenkins scream. So in order to use global libraries, your life reason to be in a repository and in our case isn't get up and your groovy court needs to be in this directory structure. Okay, so the source folder contains groovy court that you can important your script. The vast folder contains school record that defines global functions that you can use in your script, and the resource is folder contains anything that is known groovy or what you might consider resource like a Jason XML or text falls, etcetera. So, going to the fast folder, you can see that the names off each grief all should be camel cased, starting with lower case letters. First, the global functions that define here will appear in a global variables references under pipeline Syntex off the job. And if there's a matching text file like what we have here for the streets, Nice Swiss knife dot Groovy. That is the documentation that were appearing a global variables preferences Peach the textbook and continue html markdown or just plain text. We take a look at that later. So how do we load the global libraries into Jenkins? We go to manage Jenkins configure System and go to the Global Pipeline Library section. Okay, which is over here. We click on it and we call our library pipeline shed library and a default version, which basically means you're Brian's your tech version and get up. Ah, well, use master here and we leave the other options as default. The retrieval method will be more than SCM and we'll choose. Get up, selecting the credentials, putting in the owner and selecting part lines. Shit, lib and arrest will leave as defaults and will save it. Okay, so since these libraries will be used globally, any part line the system can call them and they are considered trusted. So which means that they can run any method in Java groovy, calling Jenkins internal AP eyes or even party libraries. So be very careful to got access to the court repository so that no one can push court into repository unless they have the right permissions to Okay, now let's show how we can we use our global functions from this library. As you mentioned before. The global functions are defined in agree fouls in the vast our tree, and we have defined a groovy foul called Swiss Knife Groovy, and we have moved the print name function in a previous video into these groovy foul, and we will be calling this function in the Jenkins job. The matching Swiss knife dot tex foul contains the documentation for Swiss Knife groovy, and it needs to have the doc text extension, and in this example, we just use plain text. But he can contain Hisham El or even marked down for the documentation. So let's now create a Jenkins job. So we are using the Net library pipeline shed lip syntax to loading library. Take note of the underscore next to the line. In this example, we only need to use global variables or functions, So the underscore is indicating to Jenkins to import or global variables or functions, and in the steps we are calling the function Swiss knife dot print name sending in the parameter John and all this is happening inside the script. Block less safe and run the job. Now the script checks out the library from get up and excuse the function with Prince, which prints out the name John. Now, when we go into pipelines steps Sorry, Pipeline Syntex here and global variables reference all the way down. We see that Swiss knife global variable is is here, and that's the documentation that we saw earlier. So these are the other global variables or global functions that you have probably seen it just now in get up will be encountering them in the later videos. Next, we will show you how to call a different brunch off the shed Library on it, huh? So going back to get up. We have already created a deft brunch off the shed library. So let's select that now. Okay, going into the boss directory and let's open up the Swiss knife. Groovy. So you can see that Thestreet snipe. Don't groovy to function here, Princella and issue hollow in front off the name. So if you want to use this version off the library, we have to change the public script to use that brunch. So Let's go back into the Jenkins job. So if you want, specify the deaf brunch off the pipeline. Shet library. That's how you do it. You put a at def in here, Okay? And don't forget the underscore at the end of the line. Now let's rerun the job. So now you see that? Hello? John is being printed out. This tells you that a deaf branch of the library is used now, going back to configure now instead, off using the death brunch. You can also specify attack label here. And if you want to use multiple Shet libraries, this is how you would specify it like this. Okay, so this will be the other shit library here. Okay. Know that if you just want to make use off global variables or functions, which is those in a vast territory, you can also use a difference in texts like this. Okay, so this law said the library dynamically, This is not an issue if we just want to use global functions or variables. But when we want to refer to types in the source directory, then the compilation off the script will fail. That's because using the library syntax though, is the library only after the Scriptures compound. So if the script uses some class in the source directory, it will not be able to find it during compilation. We were cities happen in another video I hope you find is useful. Let's move on to the next lecture. 48. Declarative: Importing Libraries: in this lecture, we take a look at how we can make use off libraries under the source folder, So let's go inside. Source. Com accelerated Skew up, and that's going to this calculator. Don't groovy foul. So in this foul we have a single function here called and which adds up to numbers, and that's it. So let's create a job to see how we can use this function now. We declared the library as before two important library, but now we have to do an import off the package and where we want to call the function. We need to create the calculator, object first and call it a function on it. Also, take note that we're using the Prince Line function here, and it's agree function for printing outlines easily. We could have used the echo step, but because we are returning, an integer and not a string echo step would throw an error, and all these is happening inside the script block. Let's run the job and see what happens. So from the console, you can see that three gets printed out. I hope you find is useful. Let's move on to the next lecture 49. Declarative: Importing Class Libraries: In this lecture, we take a look at how we can make use off classes in our shed libraries under the source folder and also how we can use pipeline steps in our classes. So greens going inside source calm salaries that skewer. We have a Kardak groovy foul here which defines a car class with properties, number off doors, brand model and available court script. The whole the pilot script object which is sent Environ the constructor. On top of that, the car class as a single function called print All car and in this function were using the echo step from the pipeline script object to print out the properties of the car. That's great a job to see how we can use this class. So we're using the X libraries intact. So important Shed Library know that we do not have a underscore at the end of the line here , and we also important package of the class we want to use. And inside the script block, we create a car object sending in this which represents the part line script object. The current's problems script object, assigning values off assigning values to the properties of the car and calling the principal function. Let's run the job and see what happens. So as you can see the car puppies are printed out. Now, going back to configure. I want to demonstrate that we will not be able to use the dynamic version off the library since extra import the chef library. Now let's change the script to use this Syntex okay to vote the library. Now when we use this in Texas, the library's loaded only after the script is compound, so the script will not be able to find the type car during compilation. Let's rewind the job to see what happens. And, as expected, we are encountering the unable to resolve class car era I hope you find is useful. Let's move on to the next lecture. 50. Declarative: Importing Static Libraries: in this lecture, we take a look at how we can make use of static methods in classes in our shed libraries So goings going in sight source calm s salary to skewer. We have a validator. You tills don't groovy foul here, which has a single static met the or function quote validates input which accepts a single parameter court scripts which is basically the pipeline script object which will allow us to call the echo step. Okay, so let's create a job to see how to use aesthetic method. So we are using the library. Syntex, unload the shed library. Take note that we are not using the underscore ready on the line Here in the next line, we are importing all static methods. Vier this in tex okay, And in the script block, we can call the validates input function directly. Let's run the job and see what happens. So as you can see the echo step in aesthetic method is called another way. Where you can call the static method is by loading that library dynamically and calling the fully qualifying name off the method. Let's see how this looks like. So what we're doing here is a loader library dynamically in the script block and called a static method. Instead of declaring the import at the top of the script, Let's run the job and we get the same upward I hope you find is useful. Let's move on to the next lecture. 51. Declarative: Custom Steps: In this lecture, we take a look at how we can create and call custom steps from our shared libraries. So in order to creates custom steps, we need to have a groovy foul inside a vast folder. And in this example, we took a look at exactly even dog groovy Fall in here we declared a function as as cold, and we declare string input parameter call options, which also has a default value off Desh Ki. You can even call other valid script steps in this custom step, and in our case, we call the shelves that the Essex Step, which comes from the workflow, durable task that plug in here to run a shell script, execute them even common with the given options parameter. That's credit job to see how this works. So we are using the library Syntex Important Shed Library and also note the underscore game to import all global variables. I know that we do not need to use a script block, but we can call it a custom step directly inside a steps block, and we are calling it twice one with the double hash, double desh help parameter and the other were using the default parameter value, which is Dash D printing out the maven version. Let's run the job and see what happens. So as you can see, the custom steps are cold. One with Desh double desh help and the other with the default value Dash B right? So you can also view the custom step under pipelines, Syntex and under global variables reference over here. So I hope you find is useful. Let's move on to the next lecture. 52. Declarative: Closures: in this lecture we take look at other ways we can create custom steps. He was enclosures. So in the vast directory, we have a groovy script called Execute in Script, where we define a coal method which accepts a closure parameter, which is basically an anonymous block off court. And in this call method, it is executing whatever block off court it is given insight. A script block. Hence the name of the custom step execute in script. So when we call this custom step with a block of script code, the custom step were executed just like how you would execute it in the pipeline script. Incite a script block To make things clearer, let's create a job to see how this happens. So we used at libraries syntax, important shtetl ivory, and we are calling the custom step execute in script and sending in a block of court. In our case, we are just printing out the environment. Variables of the show. No, that we do not need to call the execute in script custom. Step inside a script block. Let's run the job and see what happens. As you can see, the closure gets executed and environment variables are printed out. I hope you find is useful. Let's move on to the next lecture 53. Declarative: Importing Third Party Libraries: in this lecture, we take a look at how we can make use off the party Java libraries like those found in May , even Central Pipeline Scream. That's credit drop to see how we can do that. So with this example, we'll be using the at grab notation annotation toe import, the Apache Commons String you tools library. So the ed grab annotation comes from grape, which is the job dependency manager off groovy. You can check out this page for further details. Okay, so once you have imported the string you tools library here, we call it inside our script to upper case the text. Hello, world. I know that we are not using a script block. Take special note toe antic, the used groovy sandbox check box, or you encounter a one time exception that you're not able to find a class loader for grab . So let's run the job and see what happens. So as you can see the lower case hello world becomes uppercase Hello world I hope you find is useful. Let's move on to the next lecture 54. Declarative: Loading Resources: in this lecture, we take a look at how we can look non groovy. Resource of formal shed, library or resource is will need to be stored in the resource is directory. So let's go inside. The resource is calm s Elevator Scott directory and we have adjacent foul here, which will be lording into our pipeline script. So that's credit junkies drop to see how we could do that. So here we are, using the library Syntex to import a shared library. And also note the underscore here which eyes used to import everything from the shared library. So in the script block, we call library resource to give it the location of our resource and assigning to a variable. And in next line, we used eco step to print it, so that's run the job and see what happens. So as you can see, the Jason fall is printed out, I hope you find is useful. Let's move on to the next lecture 55. Declarative: Defining Pipeline Script In Call Method: In this lecture, we take a look at how we can excuse entire part line scripts in a custom step. So in the vast directory, we have a group rescript called Exact Butte or deploy dot Groovy, where we define a call method with a string parameter, which were determined Wish pipeline script to execute. Okay, so now let's create a job to see how this happens. So we are importing the shed library using the library Syntex with this example. We're calling our custom step exact beauty or deploy with the built string parameter that's safe and run the job so you can see that the built pipeline script is executed. Now let's go back to configure and change this to deploy and the Deploy Pipeline script is executed. Now let's change it to something else and apart. My script for Do Nothing is executed. I hope you find is useful. Let's move on to the next lecture 56. Scripted: Introduction: In this lecture, we introduce script up pipelines. Syntex is a more powerful way to create pipeline scripts as it allows the use off groovy in your script. No, that script a pipeline. In most cases, start with the keyword node. If you go, go for answers to script a pipeline problems on the Internet and you encounter solutions that start with pipeline, then you must recognize immediately that sometimes the decorative pipeline solution is not directly applicable to your script. A pipeline problem. It also does get confusing if you're using decorated pipeline scripting and come across solutions that are scripted pipeline based. Now let's take a look at a few basic examples off how scripted pipeline looks. Let's create a job. So at its most basic, we have a note block with an echo statement. Usually is good practices breakdown the script into stages, but it's possible to put everything into a node block without using stages. Let's run this and see what happens. Okay, so we get the echo of a statement printed out. No, let's take a look at an another example, going back to configure. So here we have a note block with a single stage court built with an echo statement. Let's run this. So here we have the bill stage being displayed, and this is the output when we use stages. Next, I want to also show you how we can use the note block inside a stage. So this basically tells Jenkins that I want to execute the echo step in any note. Later on, we will see how we can specify which no to use to excuse the ec eco step. Let's run this and see how it looks like. So, as you can see, there are two statements here telling you where the script is running in, right, Okay. And the echo step is executed. Now I want to also show you another way to use scripted pipeline without the new block going back to configure. So here we basically just pacify the stages and no, no blocking is use. And this script, that pipeline court is considered a felon. Let's run this. And there you go. We have two stages at being executed. Okay, Now, let's take a look at how we can get the eco step to execute on a slave nodes that's going to manage. Jenkins managed notes launching agents. Leave one. Okay, it's now available going back into the Jenkins job. Okay, so here you can see that in the note block were specified The label master, which is this current instance here at a top level note block and slave one in the inner no block. Now let's run this and see what happens. So from the console, you can see that we are running the stage built insight, slave. One I hope you find is useful. Let's move on to the next lecture. 57. Scripted: Docker > Image: In this lecture, we will be looking at how we can use Docker in Scripture Pipeline Court. That's Credit Jenkins job. This is a basic example where we specify an image and assign it to aim even image variable and call the Insight method to execute a shell. Commanding a continued to print out the maven version. Let's run the job. - So as you can see the container of being spun up with the image and the maven command being executed, I hope you find is useful. Let's move on to the next lecture. 58. Scripted: Docker > Args: in this lecture, we will be looking at how we can specify run arguments to Docker in Script, a pipeline coat that's created Jenkins job. So this is a, um, base example where we specify an image and assign it to a maven image bearable and will be called insight method. The first parameters to send in the doctor run arguments will be specified. Environment variable. Some envy equals to death, and the second perimeter is a closure block to call the shelves step to quote the some envy environment. Variable inside the container. Let's run the job. So from the console, you can see the container being spun up with the Desh e parameter being specified on the command line, and the wood death echo deaf is printed out inside a container. I hope you find these useful. Let's move on to the next lecture 59. Scripted: Docker > AlwaysPull: in this lecture, we will be looking at how we can get Dr Toe. Always pull in Scripture pipeline code. Let's credit Jenkins drum In this example, we specify an image and assign it to a to a maven image bearable, and we called a pool method on it. This will cause a doctor pool command to be executed and what we call the insight method. The first parameter is to send in the docker run arguments where we specify an environment variable. Some envy equals to death, and the second perimeter is a closure block to call the shelves step to echo out to some envy environment. Variable inside a container. Let's run the job. So from the console, you can see that the doctor pool common is executed and the container being spun up with the image Desh e parameter being specified here and the word death is printed out inside the container. Let's comments out of line where we call pool and rerun the job building again. So as you can see, Dr Poole Common is not executed. I hope you find is useful. Let's move on to the next lecture 60. Scripted: Docker > CustomWorkspace: In this lecture, we will be looking at how we can set the custom workspace for Docker in Scripture Pipeline coat. Let's create a Jenkins job. In this example, we will be using the workspace step to specify a custom workspace for doctor to walk in. This workspace step comes from the workflow. Doable. Task them right over here Knicks. We didn't specify an image and assign it to a maven image bearable and call the inside method to execute a shell command in the container to pronounce them even version. Let's run the job. So as you can see, the job is running in the No Doctor Custom Workspace directory, and you can see that doctor has specified the dash w parameter, which indicates that the workspace for Dr, which also happens to be no doctor custom book space I hope you find is useful. Let's move on to the next lecture 61. Scripted: Docker > RegistryUrl/CredentialsId: in this lecture, we will be looking at how can load and image from a registry your L for Docker in Scripture Pipeline Court. Let's create a Jenkins job. In this example, we will be using the week registry method off the Docker global variable. And we specify as the first parameter, the registry your l We have used this key door I all your l before in a decorated pipeline video on Docker Registry UL. So the second perimeter is the credentials i d. Kido tai all which we have used before in the decorative pipeline video. That's the credentials we are using here. Now we specify the image that we want to use same emissions before in a decorative pipeline video. And we print out the environment variable using prints, envy. Let's run the job. So from the console, you can see that we are doing a doctor pool off the image from kiddo, i o downloading it and spinning it up and printing off the environment Variables. I hope you find this useful. Let's move on to the next lecture 62. Scripted: Dockerfile: In this lecture, we will be looking at how we can build an image from a doctor foul with the standard naming off the foul, which starts with an uppercase D Dr Foul like this and scripted by plan quote. And we were making use of this guitar repository and seems before we're just building from the you buncha latest image. Let's create a junkie's job. So we are using the check out step to check off on the repository, and we're using the Butte method off the global variable Docker, and we specified a name in tech in a name. Colin Tech for Mitt. In the first parameter, we assigned a new image to my custom. You want to image, and then we run the cat command inside the container to print out the S details so that's safe and find a job and see what happens. So it's cloning. The repository is doing from the image fall and taking it the way we have specified. Spinning up the image well, it's beating up a container of using the image and printing out. The always details I hope you find is useful. Let's move on to the next lecture 63. Scripted: Dockerfile > Dir: in this lecture we will be looking at how we can specify the location off the doctor foul if he recites in a subdirectory in Scripture Public court and we will be making use off this git repository that has a single doctor foul in Dhaka Foul de IR directory. Seen this before, It just builds from the you buncha latest image. Now that's created Jenkins job. So in this example, we used the check out step to check out from the repository and using the built method off the global variable docker. We specify the name and tech here in the first parameter and in the second parameter, we specified the location off the doctor foul. Assuming that we are using the normal naming convention off a doctor found which is an uppercase de DACA foul, we assigned a new image to my custom. You want to image and then we run a ket. Come on inside the container to put out the West details Now that safety and run a job. So we see the doctor Bill, Come on here with the directory the respects fighters managed to pick up the doctor fall and booting and image from it spinning up a container from it and printing out the West. Details I hope you find is useful. Let's move on to the next lecture. 64. Scripted: Dockerfile > Filename: in this lecture, we will be looking at how we can use a custom named Dr Foul in script a public court. And we're making use off this repository that has a single doctor foul with a custom name, my custom name Doc a foul. And as before, it is just building from the latest you bunch of latest image. Now that's created junkies job. So we are using the checkoff step to check off from the repository, and we're using the built method off the global variable docker. We specify the name and tech in a name. Colon Tech form it in the first parameter and we specifying the second Pariente um, the double desh fall option. And we especially we put in our putting the name off our custom off our doctor foul in here and know that you have to put this dot at the end here to indicate the current directory or you'll get a doctor built era. We assigned the image to my custom. You want to image and we run the cat common inside the container to print out a wears details back before, So that's saving on the job. So there you go is checking out form the Give repository and the Doctor Bill. Come on. Ah, uses the double dash fall option followed by the single period. So has managed to build the image, running it and printing on the West details. So I hope you find these useful that's been formed to a next lecture. 65. Scripted: Dockerfile > AdditionalBuildArgs: in this lecture, we would be looking at how we can use additional bureau arguments when booting from a doctor foul in Scripture, partly in court, and we'll be making use of this guitar repository. There has a single doctor foul and Simmons before it is just building from the Bachelor latest image. Let's create a junkie's job. So we're using the check out step to check off from the repository, and they're using the Butte method of the global variable doctor, and we specified the name and tech in in the name Colon Tech. Form it in the first parameter and in the second permits over using the double double dash tech option to specify and not a tag. And don't forget this period here to indicate the current directory, we omit this single period year you'll get, Ah, we'll get a Doctor Butte era. So assigning the image to my custom, you bunch of image and you're running the command inside a container to pronounce us details. So let's save and run a job to see what happens. I think I kicked off the bill twice, so let's see. So is building from the doctor foul, and it's taking it twice. The first time is from the first parameter and the second time from the double dash tech. Right? So we have two texts. So doctors beans up a container from the image and it prints out the West details. So I hope you find is useful. Let's more. Let's move on to the next lecture. 66. Scripted: Dockerfile > CustomWorkspace: in this lecture, we will be looking at how we can specify a custom work space for building from a Dr file in script the pipeline code. And we will be making use off this guitar reports. Cherie. There has a single doctor fall, and as before, it is just beautiful from the U Bahn tree Latest image. Let's create a Jenkins job. In this example. We are using the workspace step from workflow, durable tar step plugging over here, and we are also using the check out step to check out from the reporter tree. We also use the Butte method of the global variable docker, and we specify the name and tech off the image in the former off name Colon Tech. And then we run the command inside a container to pronounce the S details. Let's see if I find a job and see what happens. So as you can see, we are running in this workspace and the script is checking off from the repository. Don't Go has managed to find a foul building up the image and take note that doctors best fine the working directory to be using the custom directory that were specified and we are printing out. The always details here I hope you find is useful. Let's move on to the next lecture. 67. Scripted: Stage > Options > Error/Retry: in this lecture, we think Look at the Retry and Aero step in scripted pipeline court that's created job now in scripted Pavlenko, there's more flexibility in how we can use a retry block. In this simple example, we have encapsulated the Aero step inside the retry block to retry three times less. Run this and see what happens. So, as expected, the every step was executed three times inside the built stage, and the bill ended in failure. Now let's see another example. Okay, so in this example, we have encapsulated the bill stage inside a retry block. Let's run this and see what happens. So the Butte stage was executed three times 12 and three, and the beauty ended up in failure. Now let's see 1/3 example. So in this example, we have encapsulated the entire note insight, a retry block. Let's see what happens. So as you can see that the note was executed three times, Okay, 12 and three, I hope you find is useful. Let's move on to the next lecture 68. Scripted: Stage > Options > Timeout: in this lecture, we take a look at a time out and sleep step in scripted pipeline court. Let's create a job in script a pipeline court. There's more flexibility in how we can use the time up block. In this simple example, we have encapsulated the sleep step inside a time a block to time out in one second. Let's run this and see what happens. So the sleep step caused the time auto happen inside the Butte stage, and the bill ended up in a border status. Now let's see another example now, in this example with Encapsulated the Butte stage inside a time a block. Let's run this and see what happens. So the time what happened and a Butte stitch level. Okay, so now let's see 1/3 example. So now we have encapsulated the entire note inside a time out block. Let's run this and see what happens. So the time out happened at the north level. So there are different ways in how we can make use of time out in scripted pipeline coat I hope you find is useful. Let's move on to the next lecture 69. Scripted: Stage > Options > Timestamps: in this lecture, we take a look at how we can use time stems in scripted pipeline court that's created job here. We use the time stems court blocked to encapsulate the build and deploy stages so that the Echo statements in both stages would have time stems That's safe and run the job. Here we can see the time stamps printed out before the echo statements for both stages. Okay, so Nix. Let's take a look at how we can put the times them block inside a speech going back into configure. So in here we only have the time stems block inside the build stage, but not in deploy station. Let's run this and see what happens. So only the bill stage Echo statement has times them I hope you find is useful. Let's move onto the next lecture 70. Scripted: Stage > Environment Credentials: in this lecture, we take a look at how we can use credentials in scripted by line court. That's first created job. So in here we are using the with credentials function from the credentials binding plug in . Okay. He allows us to bind credentials. Two variables, as we have already set up a user impossible credentials, which is some use, an impossible it in our previous videos, we can use them here in this example, and we are using the user name posturing bindings binding here. There are other bindings listed in the credentials binding plugging page. So let's search for user name password. Right, They go. So this is where the documentation for using impassable binding is found. Okay, so we are setting the using variable to some user name and the possible variable to some password and within the credentials within the with credential block, echo the user name and password. So let's save the job now. And I would like to take this chance to show you where the credentials are stored. So we go to credentials here, and these are the credentials that were previously created. We have C some using pastorate credential here and the some secret credential here, which you're used later. Okay, so let's run the Jenkins job. So from the console, we can see that only s tricks are printed out for the using. Impossible. Now let's see how we can use multiple credentials in our script. A pipeline court. So going back to configure as mentioned before you know, previous videos. We have created a secret text credential, and we'll be using that here. As you can see, this is how we specify multiple credential bindings, and we're using the string binding for secret tanks. Okay, so if we search for string So this is the one they were using? Okay, let's run the job. So it s expected. Only s tricks are printed out. Even forced to critics I hope you find is useful. Let's move on to the next lecture. 71. Scripted: Stage > When (Part 1): In this lecture, we take a look at how we implement the wind directive in scripted pipeline. Let's create a Jenkins drum. So here we have defined to normal variables name and is groovy cool and using the wif e N V function, we declare a deploy to environment variable that can be used within the with envy and closing block, which also has a built station it in abuse dish. The wind environment equals expression not or off, and any off conditions are all represented by his groovy equivalents. For when environment we're testing for the value off the envy dots deploy to variable for the wen equals condition. We're testing for the value off the name variable for when expression condition. We are testing for the value off the east. Groovy, cool, variable and so on. So forth. Let's save and run the job to see the output, so the output is what we have expected. I hope you find is useful. Let's move on to the next lecture 72. Scripted: Stage > When (Part 2) > Branch: in this lecture we take a look at how we implement the brunch condition off the wind directive In scripted pipeline coat, we will be making use off a guitar repository script that went brunch. And in it there's a single Jenkins fall. And in here there are two stages built, master and build Death. Not exactly sure why the formatting is off, but I think you should be able to understand it. So we are using the environment Variable brunch name here to find out which brush of court we are building four. So if the branch name is master we built, we execute a stage built master. And if the brush name is deaf, we execute the stage book death. So there's another branch court deaf which has exact same Jenkins fall. So let's don't create a Jenkins job. So this is gonna be a multi branch pipeline job, adding the get up source saving it. Okay, now let's take look at the Master Butte. So the built master states was executed by not built deaths teach. Let's take a look at the death build so we can see that a built master states was not executed by the built deaths. Teach wars I hope you find is useful. Let's move on to the next lecture 73. Scripted: Stage > When (Part 2) > BuildingTag and Tag: in this lecture, we will be looking at how we implement building tech and tech conditions off the window. Active in scripted public court. We will be using a guitar repository and you need There's a single Jenkins fall. We have ive conditions that test for the environment. Variable tech name. So when the environment variable technique is not know, we are building from attack and if it is now we are building from a brunch. If you want to, detective, you're building from a specific tech. We can compare the value of the Technion variable to that specific tech, which is what we have done here For release 1.0. Note that we already have two tax here in this repository. Released 1.0 and released 2.0. They're all pointing to the same Jenkins fall. Let's create a junkie's job. This is gonna be a multi branch pipeline job, adding that get up source. Remember toe at Discover tax saving it. Now let's go into the master branch build. So because the tech name is now, that's why is printing out. We are building a brunch. Now let's take a look at the release. 1.0 Tech doing a manual built so it's going to see the correct statements are printed out. Now let's take a look at released 2.0 so we can see that only one statement was printed out . I hope you find is useful. Let's move on to the next lecture. 74. Scripted: Stage > When (Part 2) > Changelog: In this lecture, we look at how we can implement the change lot condition off the wind Directive in Scripture partner in court, we will be making use off a get high repository which has just a text fall normal dot techs which contains some arbitrary texts. We will be making changes to this text fall so that we can put in different commit messages and we run the builds that's created Jenkins John. What we're having here is mainly groovy court. Firstly, we check out the falls from the repository and then we declare a boolean variable change look found. That tells us we have found a change law, which is a common message. That's roots a certain pattern. Next we declare a change. Locks that variable and assign it be changed. Set property off the current built environment Variable. We didn't print out the size off. The change looks set. We looked through the change blocks set and get each commit message. Know that we are also printing out the class name often elements off the change lock sets. We will refer back to this soon. If the comet message for fuels the regular expression here change. Look found variable will be set to true. And then we break out off both four loops. No, that after the follow we said the change box sets variable to be No. This is to prevent Jenkins from serializing the variable as available contains get change set list object which is not serialize herbal. Otherwise, we will be getting not Ciruli, but it's not serialized exception. You know Jenkins script it changed, not found is true. The change not found stage will be executed. If not, the change lock, not founds. Teach will be executed. Let's save the butte and run it as is as this is the first built, the built skips the change law. Now let's make a change to the text file and commit the fall. - Now let's rerun the bill. We see that a comet message refused the regular expression and the change lot found Stich is executed. Now let's change the text of the text file again and give it a common message that does not fulfill the regular expression that's rerun the built. We see that a common message does not fulfill the regular expression and a change law not found stage is executed. I hope you find it's useful. Let's move on to the next lecture 75. Scripted: Stage > When (Part 2) > ChangeRequest: In this lecture, we look at how we can implement the change request condition off the Wind directive in Scripted Pipeline Court. We will be making use of a guitar repository which has the Jenkins fall in a normal text fall that contains some texts. We will be making changes to the text fall so that we can commit a foul and create pull request. And in the Jenkins fall, we are printing out all the environment variables related to change request or pull request . And we have an if condition that checks if the pool request Tyto is equals to NPR. We echoed that we have found a pull requests. If no, it prints are pull request not found. Semen that's created Jenkins job. We will be selecting a multi branch pipeline job, adding to get up source saving the job. Let's go to the master built. So as you can see all the values of the change request, variables are now as it's not a pull request built. So going back to get up, let's create a new death brunch and going to the console, get pool and we're checking out the death brunch. Let's modify the text off the normal doc text foul. Let's change it. 2 to 3. - Okay , let's refresh the get up page. So a normal dot tex has already been updated. Now let's create a pull request that's putting the title to be Wen PR. That's what we're looking for and create a pool request. Okay, Going back to Jenkins that scan the repository again, and the pool requests is picked up so you can see there's one poor request here. Let's take a look at the locks, okay? So we can see that the change title is when PR and I'll pull Request is found and the other environment variables for change requests are populated, except for a few of them I hope you find is useful. Let's move on to the next lecture. 76. Scripted: Stage > When (Part 2) > ChangeSet: in this lecture, we took a look at how we implement the change Set condition off the wind directive in script that pipeline court we were making use off a guitar repository which has just a text fall and a JavaScript phone. Wolf contains some texts. We will be making changes to these falls so that we can commit them and read Run the builds that's created Jenkins job. What we're having here is mainly groovy code. Firstly, we check out the falls from the repository. Then we declare a boolean variable change set phone that tells us if we have found a change set which involves JavaScript falls the ends with dot gs. Next we declare a change lot set variable and assigning the change set property off the current built environment Variable. We don't print out the size of the change lock set. We looked through the change box sets and get each phone name. No, there were also printing out the class name often elements off the change lock sets. We will refer back to this soon. The father was changed, has a fountain in the ends with dot gs. Change that phone. Well, we set to true we didn't break out or both. The for loops. I know that after the follow, we change the change. Lock sets variable Toby. Now this is to prevent Jenkins from serializing the variable as available Contains get change set list object, which is not serialize herbal. Otherwise, we will be getting not serialize herbal exception in the Jenkins script. If the chance that found is true, the chase that found stage will be executed. If not, the change set not found, speech will be executed. Let's save the beauty and run it as it's the first beauty. The beauty skips the change law. Now let's make a change to the JavaScript foul and commit the fall. - Now let's kick off the bill. We see that the phone name and ST dot Js and the chase that phone state she's executed. Now let's change the text of the normal doc text file and committed. Let's rewind the build again. We see that the founding does not end with dot gs and the change not change sent, not found. Speech is executed. I hope you find is useful. Let's move on to the next lecture 77. Scripted: Stage > Parallel/FailFast: in this lecture, we will be looking at how we implement the peril block, including a fair, fast option in script a public court. Let's see a simple example. So this is a syntax for running peril court in Script a public court. I know that there is only just one stage three branches here and the field fast option. So each branch is such asleep for 10 seconds. Let's run the job to see it in action. So from the console, you can see that it is described here as brunch instead of stage. And even on the Mean Jenkins job page, you can see that there's only just one speech. Now let's change the script to run sequentially. So, as as before, his stage is also sleeping for 10 seconds. Let's run the job, Okay, so you can see that is executing in sequence. Let's go back to the main Jenkins page. You can see that they are three stages here to see how fail fast works. Please view the decorated part line video on running payroll stages. I hope this has been useful. That's been for answer. Next lecture 78. Scripted: Stage > Input: In this lecture, we will be covering how to implement input in scripted pipeline court that's created junkies John. So here we have declared a variable called user input, and in the build stage, we have assigned the return value of the impulse step to the user input variable. And once the user proceeds with the input, we echo out what the user selected using the user input variable like user input, the environment, user input up version and etcetera. The parameters to the impulse step should not look unfamiliar to you as we have already covered them in the decorative pipeline videos, Let's say from on the job and as expected, the script prints out the user input. Now what if we want to ensure that if the user does not key in the input in a period of time, the beauty doesn't get stuck? What we can do is to wrap the input court in a time out block. Let's take a look. Now we have wrapped the input inside a time out block and for the sick off demonstration were set a time out to one second. Let's run the job. So as you can see even if there's no user input, the bill times out and ends up in a border status. However, it does not get stuck. I hope you find is useful. That's move onto the next lecture. 79. Scripted: Stage > Post: In this lecture, we take a look at how we implement post in scripted pipeline court that's created Jenkins jump. So what we have here is a try catch finally construct, which comes from groovy. So if you know a language that has the same constructs, you wouldn't be too unfamiliar with how it works. So for those who are unfamiliar, try, catch Construct is used to execute a block of coat and to handle any exceptions that might arise from it. The finally block is used to execute court once the try block completes. The cash section here doesn't do anything in this example, but I have listed it just for the sake of completeness off the try catch finally block. We can also just have to try and finally sections. Only the finally section is where we in prevents post so you can see that they are fair. Number off if conditions their checks for status is off. The current build and the previous bill to decide whether to execute the court that it encapsulates the script of Portland Court has County set the currents built to success. So let's just run the court and see what happens so I can see the always coat is executed, success stories executed and a cleanup court is executed. Now let's go back to change the status of the butte to be aborted. That's safe and run the job again. You can see that always quote change, court regression quote and a border court and clean up court is executed. Executed. Now let's change the status of the butte to be unstable and see what happens. You can see that now. The unstable coat it is executed. Now let's change it to be failure and the failure court is executed. We can also put this try cash blocked with dinner stage so that only runs within a particular stage. Let's take a look at an example. So here we know only have a built stage, but also a deploy stage, and the try cash block is within the built stage. Okay, so now let's save the job and run it. So, as you can see for the deploy stage, it only prints out the echo statement I hope you find is useful. That's one. Let's move on to the next lecture 80. Scripted: Options > BuildDiscarder: in this lecture, we look at how we can implement built Discover option in scripted by plane court. That's great. It Jenkins dropped to see how we can do that. So what we have here is we specify the bill, discover property to the pop dysfunction and were specified to keep the build locks to just one for demonstration purposes. Let's save and run the job all good there. Let's rerun the job. Begin, and we've got to refresh the pitch. To see the only one build is kept. Okay, so built to is the only one that's kept. That's bute. And at a time, three. Let's refresh the page. Okay, so only built three. It's left, I hope you find is useful. Let's move on to the next lecture. 81. Scripted: Options > DisableConcurrentBuilds: In this lecture, we take a look at how we can implement this able, concurrent built in script, the part line court. Let's create a Junkins drop to see how we can do that. So here we have specified that this able concurrent bills property to the properties function and in the build stage, because the bill to sleep for 10 seconds so that we can show concurrent bills are prevented when this able concurrence builds, properties must fight that's safe and run the job. So let's run multiple builds build one built to his spending, waiting for built one built three spending waiting for built to so you can see that subsequent beauts are pending, waiting for the previous built to finish before executing. Now let's comment out the disable concurrent Bills property and also remember toe uncheck this tick box right that do not allow concurrent boots tick box and that's comment out that property. Let's save it, and that's rerun the built multiple times. So now you can see the behavior is different. I hope you find is useful. Let's move on to the next lecture 82. Scripted: Options > OverrideIndexTriggers: in this lecture, we take a look at how we can implement overwrite index triggers unscripted Pipeline Court. We will be making use of a guitar repository which contains the single Jenkins Fall and in the Foul. We have initially commented out the overall index triggers property first, and we have a built states wish which prints out Hello, World one. Let's create a Jenkins drop selecting a multi branch, part line job, adding a get up source. Saving the job now a schedule built was created for master brunch Going to master and we see Hello World one printed out. Now let's I'm commend the override index triggers property and set it to false to disable brunch. Indexing triggers and we're changing the Hollow World Toe Hollow won't to. Okay, so I will be using a comet script to help me automate the committing and pushing off court to the repository by the git commands are essentially the same as before, So we've got to get at get come it and get pushed origin commands as before. So let's scan the repository. The bill is scheduled for master brunch. Are we going to the must brunch and we see that Hot awoke to is printed out now for the overall index triggers property to take effect. We do a manual build. Okay, How the world to is printed out. Now that's change to hollow. Whoa. Three and committing it. That committing the change to Repository. Let's scan the repository again. Now the built is not scheduled. Okay, so now let's set the over index triggers to true setting. Hello, World 24 Saving it and pushing to the repository. Scanning the repository. The bill is still not scheduled, as do a manual built. You see that we see that hello world voice printed out. Let's change too. Hello, World Five and pushing it to the repository. Okay, now let's scan the repository and you can see that the built is scheduled. Now let's going to master and we can see how the World five sprint so I hope you find is useful. Let's move on to the next lecture 83. Scripted: Options > SkipStagesAfterUnstable: In this lecture, we take a look at how we can implement skip stages after unstable in scripted partner in court. That's created Jenkins drop to see how we can do that. So here we have two stages build and deploy in the build stage will be set, the currents built to be unstable and before executing the deploy states, we checked. If the current bill is not unstable, which it won't be and the Deploy stitch is expected to not get executed, let's run the job so you can see the only the build states was executed. Now let's change the Butte status to success, for example, and rerun the job. Now both stages are executed. I hope you find this useful. Let's move on to the next lecture. 84. Scripted: Options > CheckoutToSubdirectory: In this lecture, we take a look at how we can implement Check out to subdirectory in Scripture. Pablo. In court, we will be making use off get have repository, which contains only a single text file. Let's create a Jenkins job. So here we are using the Ws step, which allocates a new workspace. This step comes from the workflow, durable task that plug in over here and we called a check out step. He will check out into the new workspace, which is the subdirectory off the junkies job workspace. Let's run the job from the console. You can see that the job is running in this book space. Right now that's going to pipeline steps. Look it not start going to the workspace, going to some sub D i r. And you can see that a normal doc text file from the repository was checked out into this directory. I hope you find this useful. Let's move on to the next lecture 85. Scripted: Options > NewContainerPerStage: In this lecture, we take a look at how we can achieve the same behavior off new container per stage option Off the option directive in Scripted Pipeline Court. Let's create a Jenkins job. So what we have here are two stages, and in each stage we specify an image and assignment to a maven image bearable and called inside method execute Shell commanding a continent spring, autumn, even version. It's essentially the same as a script of pipeline example off Docker image, but with more than one stich. Let's run the job looking from the console. The container I d is different for each speech, right? And you can see that the container starts and stop within each stage. Okay, so I hope you find is useful. Let's move on to the next lecture. 86. Scripted: Parameters: in this lecture, we will be looking at how we can implement parents is unscripted pipeline court that's created Jenkins job. So what we have here is specifying the parameters property together with the kind of parameters that we want to use, like string bullion. Param Choice. Possible it fall, etcetera. We have already seen the parameter types before. You know, declarative feed pipeline videos, four parameters. At the end of the script, we print out the values of the parameters using the parents object. Let's save and run the job. We will need to run the job at least once to configure the built with the parameters before we can run the job again. We've parameters, so we have now run it once that's refreshed. A peach. Now you can see that the built now link has changed to build with preventers. Let's click on the link and we are presented with the permits is here. So let me just click on build and we can see that these are the parameters that were selected. Now where we going to the configure screen, you will see that we have additional options here to choose from. These came from unscripted pipeline coat I hope you find is useful. That's move onto the next lecture 87. Scripted: Tools: in this lecture, we will be covering how to use tools in scripted pipeline court. Let's created Jenkins Trump. So here we have declared available cult me even home. And we are using the to function to specify the tomb that we want to use and the type of it the tools that we want to use need to be pre configured under global to configuration in managed Jenkins. Two versions off, maybe in our really installed and configured on our Jenkins server. So let's take a look at that in global to his configuration. So we go to manage Jenkins Global to integration, maybe an installation. So we have these two maybe in installations here. Okay, so after we have assigned available, we called the shell step to print out the me even version. If you want to use other tools, you can go into pipelines in Texas and use a step a generator that saves a job and go there now, going into pipelines in Tex snippet generates, Ah, that search for tool. And if you select me even you'll find that the two maven installations that we have seen before I listed here and we click on generate pipeline script to get the course nipper that we can use in our public script. So let's now run the job. So from the console, we can see that the correct maven version is printed out. I hope you find these useful. Let's move on to the next lecture. 88. Scripted: Triggers > Cron: in this lecture, we take a look at how we can implement the corn option off the triggers directive in script apart plan could That's credit Jenkins drop. So here we are, using the pipeline triggers property, and we have specified the corn expression here. I have a really cover what acorn expressions are in my previous videos on Cron, so I won't be covering them here. You can also use the other variants of the corn expressions which are committed out here. Okay? And we have ah, bill station that prints out Hello, world. That's ah, safe and run the job. Okay, so we see how the world printed out here. Going back into configure, we find a new section built triggers and you'll see a corn expression in the text box s in the previous videos on Cron. So I hope you find is useful. Let's move on to the next lecture 89. Scripted: Triggers > PollSCM: in this lecture, we take a look at how we can implement Po SCM option off the triggers directive in scripted partly in court. And we will be using a good have repository. There has a normal dot text file that contains some texts so that we can make changes to it and we run the bills. Let's create a Jenkins job. So in here we are using the pipeline, triggers property and have specified and have specified a poor SCM expression here. We have specified to Jenkins that we want to pull get up every minute, every hour, every day of the month, every month and every day of the week. And we are also using the check out step here in the Butte stage which will check out the court. And in our case, there will be normal texts so that safe and run the beauty OK, all good here. Now let's go back to Camp Leader and you will see a new section here under Bill Triggers, which has the polling configuration, that we're specifying our script. I would also like to bring to your attention this link here, get pulling log where you can see when the report was last polled. Okay, so now let's update normal dark texts and commit the changes. Okay, so we've changed the normal text from some text. Want to some text to and I'll be using a comet bench foe? Yeah. Comet script batch, file toe automate the commune and pushing off court to the remote reports tree. So as we have set the polling to every minute, we will refresh the polling locked page to see there. Any changes? So changes have been found and a new built as kicked off. Okay, so that's going to pipeline steps. Okay, Not start. And we see that normal Texas, the latest texts. So I hope you find these useful. That's move onto the next lecture. 90. Scripted: Triggers > Upstream: In this lecture, we take a look at how we can implement upstream option off the triggers directive in script up battling court that's created Jenkins job. So what we have here is the triggers property where we have specified the upstream parameters, which tells Jenkins that this drop is to build when upstream job scripted upstream drop one and two. Our butte, We've a success. Did this available status is unstable failure, not Butte and aborted. And the class type to use is Jenkins triggers rivers built trigger. Now let's save this and create the option jobs. So I'm now just going toe open all three jobs in different taps and I'm gonna run jump one . OK, all good running job, too all good as well. And let me just run the main job for the first time. Okay, So going into configure, you'll see that there's a new section under Bill triggers with the configuration that were specified in the script that ah, pipeline quote. So now let's run job one. Okay. So we can see that the, um built two of the main jump has kicked off. Now that's Ryan job too. Built three has kicked off off the main. Ah, built Three of the main job has kicked off. Now, let's set job one to be unstable. Okay? And that's built job one. Okay, going back to the main job. We just before a few seconds. You just refresh the peach as well. Okay, so no new built was kicked off. Now, let's Ah, kickoff job too. Okay. And built four was kicked off, so I hope you find is useful. Let's move on to the next lecture. 91. Congratulations!: congratulations and thank you. You have made it to the end of the course. We have covered a lot in this course, and I hope that it has accelerated your understanding and application off. Jenkins Pipeline is code. Please take the time to leave a review and rate the course. If you have any feedback on how I can make the course better, please let me know so that I can improve. And if you also have any questions that you had that I do know answering my lectures, please feel free to message me. I will continue to add more lectures to the course. So this is not a final version of it. Please let me know what topics you want me to cover. So once again, congratulations and I was see online. 92. Bonus Lecture: How To Get Output Of Shell Script: in this lecture, we will be looking at how we can get the output off a shell command and assign it to a variable. They are usually two things we want from executing a shell command or shell script, the output of it or the exit status of the shell script. So let's take a look at how we can achieve that. That's created Jenkins job as we want to capture the output of the shell scripts or variable. We can do that in scripted syntax or inside a script block in decorative Syntex. But with this example, we will be using scripted Syntex. So, as you can see we have defined are variable called shell output, to which we will be assigning the standard output off the shell script. We use the shelves that which you can get from the nose and processes. Plug in right here and we were specified. A script Perimeter Toby ls Dash L and well, which basically returns to the directory contents and the return standard out parameter to be true. This tells the shell out. Put the show step to return the standard output. No, the tree method that is called at the end of the shell step. This trips to return output to remove any trailing new lines. For the second show step, we specify another parameter return status to be true, which tells the Shell stepped to return the exit court of the Shell script for the third shell step. We give a negative example where the Shell script returns a non zero value, which usually indicates an era. We will come back again to this commented out court later for the fourth shell step. We specified both parameters, and we see which permits a takes proceedings as to what is being returned that's safe and run the job. So from the console output, you can see that the return value for the first shell step is the output of the script. Okay, now the second shows that returns the positive exit status off the script and the shells that returns a negative exist status of the script and 1/4 shelves that returns the exit status off the script, which tells us that the return status parameter takes proceedings over the return standard out perimeter when both are specified now, going back to the configure page. That's no UN comment the court that checks for the return status of the script, and we wonder script again. This time you can see that we have made the bill. Tofail, based on the return status off the script I hope you find is useful. Let's move on to the next lecture. 93. Bonus Lecture: How To Create Env Variables For Shell Script: In this lecture, we take a look at how we can create environment variables and use them in a shell script that's created Jenkins job. Here. We start off with creating two variables, one that starts with E. N V and the other groovy variable. We assign envy dot e N V var. Want to be joined and a groovy variable to be Smith. Okay, we use the show Steptoe echo the environment variable in a shell script, and we used the Echo step to print out a groovy variable, not envy via one in the pipeline script. Take special note that both these echoes are different. One works within the Shell script and the other in the Jenkins Pipeline script. Next, we try to print out the not E N v von one groovy variable Inside the Shell script Knicks. We were used the with envy step, which you can find it here. Okay to specify one or more environment variables that can be only be used within a block. And here we have E N V var, too, and we have envy N version. Within the bloc, we use a shell step to pre now the value off envy bar to okay. And also to execute the maven or envy n command to get the maven version. And lastly, we print out the prince with printout order environment variables available within the shell script inside the block using prince envy. Common. Now, once outside the block, we print out the envy of ah to and the M V n version environment variables to see if they exist outside the with envy block. Now, let's save and run the job. Okay? So I'm just gonna be putting the console output and the coat site by site. Okay? So we can see that we are able to print out the environment. Variable envy, Vaal One. Okay. In the shell step right here. Okay. And we are able to print out a groovy variable within the pipeline script so you can see that we have Smith printed out here. But however, we are not able to print out the groovy variable inside the shell step because it doesn't exist. Okay, Now, as we move to the e envy the with envy block right year. Okay, Maybe it just moved this to the bottom. You can see that we can print out envy, Bottu. Okay, which is groovy. Right? And we can pre not the maven version. Okay, let me just scroll down and we can print them even version here. Okay, Envy end, double dash version. Okay. And we can find that the e n v Vaughn to Okay. Envy vault, too. An M v inversion. An old soul, E n v. Vaal One. Okay, we sure specified at the top of the script here. They're all available within the the shell script. Okay. Inside the with envy block. Now, after the with envy block, we try to pronounce the envy of ah two and the M V m version environment variables, but they do not exist. Okay, I hope you find is useful. Let's move on to the next lecture. 94. Bonus Lecture: Pipeline Maven Integration (Part 1): In this lecture we cover maven integration by using the with maven step which configures a maven environment to use within a pipeline block. We will need to have this plug in installed in our Jenkins set up in order to demonstrate this plug in. We have a Java maven project in here with its own palm dot xml, a calculator class and its own test case. Let's create a Jenkins job. So here is the first example of using the with maven step. First we clean the workspace and we do a get pull of the Java project into the workspace. Next we have the with Maven block and we have specified a maven parameter here that points to the maven installation we have configured in Jenkins Tools Configuration. You can see that we have to maven installations on the system maven 352 and maven 305 Now going back to create Jenkins Job page and within the with maven block, we call M V n Clean install. Let's save and run a job. So from the console, you can see that we're using Maven 305 to compile the Java project and the job is run successfully. So now we change the maven version. 2352 Let's do just that. Going back into configure, we change it to 352 and rerun the job, and you can see that the Maven version is now changed to 352 and the build is successful. Before we go to the third example, I just want to show you we have a few repositories set up in their locations. We have one repository here for maven version 305 and it's not empty as it was populated by the previous bailed. And here we show the repository that may even 305 is pointing to We have another one for maven version 352 and it's not tempted due to previous builds. And here we show the repository that may even 352 is pointing to, and we have another one here. Config. File maven Repo. We will be using that later, and we have another one here called local maven Repo empty as well, and I will be showing how we use that later. Okay, so let's go back to configure and take a look at another parameter of the with maven block . So in this third example, we have a parameter here that specifies a local repository. This repository points to the local maven repository, which I have just showed you, and this repository will be used instead of the one specified in the settings dot xml in the Maven 352 installation Take Calls a special note of the dash X parameter that I have specified in the envy in command. This will print debugging messages that will let us see which repository is being used. We now remove all contents in the Maven 352 Rebo just to make sure that we're not using it . When we run the job, let's run the job from the console. You can see that we're using the local maven Repo and also the Global Navan settings is taken from the maven installation. But clearly this value here is overriding whatever that is said in global settings. Now let's see if the Maven 352 repo is populated or not. Okay, so it's still empty. Now let's go to local maven Repo and we can see that the artifacts are downloaded to this directory. Let's now take a look at another parameter called the Maven Settings Config parameter. Going back to configure here we have specified that we want to take the maven settings from a configuration file that is pre specified. You can see that we have a blank value here, which we will need to fill in. This value is specified and Jenkins managed files. Let's save this job first going into managed Jenkins managed files. In order to have this available, we need the config file provider Plug in. Let's now create a new maven settings configuration parameter choosing maven settings dot xml putting in the name and comments. And here we specify that the repository location to be used His CONFIG file may even repo. Let's save it, copy the idea and go back into the Jenkins job, pasted as the value of maven settings. Config parameter note. Also of the dash X parameter that we have specified as part of the M V N Command. This isn't a bugger flag which will help us. Seymour Information inside maven going to the command line. We remove all artifacts in the maven 352 repo just to make sure that maven is not using this repo. Let's run the job. So from the console, you can see that maven is using the config. File maven report not the Maven 352 Repository. Let's go to the command line. We list the contents of the maven 352 repository and we see that it is empty. Now we list the contents of CONFIG. File maven Repo. We see that the artifacts air downloaded here maven is still using the global settings dot xml of maven 352 But the setting specified by maven settings config parameter takes precedence. 95. Bonus Lecture: Pipeline Maven Integration (Part 2): There is also another maven setting called Maven Settings File Path, which allows us to specify the location of the settings dot XML that we want to use. So let's go back into configure. This is the maven settings file path parameter, and we continue to use Maven 352 But we specify the location of our settings dot xml file to be made in 305 Going to the command line. We remove the contents of the maven 305 rebo and show that it's empty and we remove contents of maven 352 Repository as well. And we confirmed that it is empty. Let's save and run a job so you can see that Maven 305 repository is being used, which tells us that maven settings file path parameter is, in effect. Global settings Air Still for maven 352 going back to command line, we list the contents of the maven 305 repository, and the artifacts are downloaded there. Now we list the contents of the Maven 352 Repository. It's empty, so Maven is still using the global settings dot xml of Maven 352 but the settings dot xml specified by maven settings File Path Takes precedence Now what if all three parameters Maven settings file path maven settings Configured maven Local repo are specified? Let's take a look Going back into configure We have now specified all three settings. Maven settings file path maven settings. Configured maven Local Rebo maven is using 352 maven settings. File Path is pointing to maven 305 for maven settings. Config. We go back to manage files and copy the I D and Paste the Value Here Now maven settings configures pointing to config, file maven, repository and may even local repo parameter points to local maven repository. Let's run the job to see what happens. So local repository is using local maven Repo, which tells us that maven local repo parameter takes precedence, is over the other settings. Now what if we remove maven local repo parameter? Let's go back again to configure and remove maven local Rebo. Let's save the job. Do a fresh build Now The repo being used is the one from the CONFIG file, which is config. File may even repo going back to configure. This tells us that between maven settings, configured maven settings, file path maven settings, config will take precedence. There is another parameter that I would like to show in. All previous examples were using Job eight. But if we wanted to use a different job a version we can use the Jan de que parameter let me just copy the new example code. We add the J. D. K parameter and here to use Java. 11. Take note that John 11 needs to be pre configured and managed Jenkins Tools configuration. Here we have Job eight and John 11. Let's go back to the Jenkins job, save it and run the job going by the console. The Java version is Job 11. There is another parameter called maven ops, which allows us to specify Java options. Take note that this is not specifying maven options. Let's go back into configure. We have added the maven ops parameter in to print command line flags and to use the concurrent mark sweep garbage collection for Java. Let's now save and run the job. So from the console you can see that the values of Java flags, air printed out and also a warning message from Java that concurrent mark sweep garbage collection will be phased out. Now when we remove the maven ops, these messages do not appear. Let's change the script and see Now we do not see the messages that we saw earlier appear last, but not least, when we go back to the main Jenkins job page, you can see that the artifacts of the build are being published. And on the right there is this test result trend graph here that shows how well your unit tests are doing overtime. If you want to enable or disable these two sections here, what you can do is going to the maven integration plug in page. Under report publishers, you can use the artifacts publisher and the June IT publisher options of the With Maven Block. Let's see an example. So here we have specified disabled to be true, which means we want to disable June it publishing and artifacts publishing, which will remove the artifacts and test result trend graph that we saw earlier. Let's were on the job and see what happens. Now you can see that you're artifacts are not published and also test result trend graph is no longer there if you want to re enable them again going back into configure, set the disabled value to false and rerun the job. Going back to the main job page, you can see your artifacts and test result trend Graf again, There are other options in here that you might want to explore further, for example, maven global settings, CONFIG and other report publishers. I hope you find this useful. Let's move on to the next lecture. 96. Bonus Lecture: Pipeline Maven Integration with Jacoco: in the last lecture, we showed you the test results. Trend chart on thing that I forgot to mention was that you can click on the chart and see what the tests are, which are passing or failing. You can click on the package to get the list of test classes and clicking on the test class . We can see what the tests cases are. In this lecture. We show you how we can use the Jiko Ko plug in to display the test coverage of your job and project. For this purpose, we will be making use of a Java project called Simple Java Project with Coco. Everything is the same as the Java project in the previous lecture. But the palm dot XML has been updated to use the Jiko Ko maven plug in to generate the test coverage. Now let's create a Jenkins job to see things in action. So here we have the sample pipeline script is the previous lecture and we want to view the test result trend graph and published the artifacts of this build. So we set both for disabled parameters to false. Before we save and run the job, our get U R L is now pointing to our new get hub project Simple Java project with Coco. Let's now save and run a job. Okay? From the council here we see the Jiko Ko Maven plugging and also the Jiko Ko plug in in action here it detects the existence of the Jiko Ko coverage files created by maven and publishing the results. Let's go back to the build page. We see only the code coverage trend graph, but no test result trend graph as we will need to run it for more than wants to have the graph appear. Let's run the job again. Now we see that the test result trend graph appears so from here we see that we have three test cases, four covered lines and one miss line clicking on the code coverage graph for the coverage report option On the left, we can see that there is a nice coverage summary and the coverage breakdown by package clicking on the package name. We see the calculator source file and clicking on that. We see that the multiple e method is not covered by our test cases. This is the missing test case and because we have imported are Java project into Eclipse i d. We uncommon the multiple test case. Commit the file and push the code to get hub. Now going back to Jenkins Page, we rerun the build. So once the build has finished, we go back to the job page and we see that the test result trend graph has shown an increase in test cases to four in the code coverage graph shows there is an increase in lines covered in a decrease in miss lines. So what if we wanted to be able to set the status of the build to reflect the code coverage of the Java project? We can do that by going into pipelines, syntax, searching for Jake Coco, and we have a whole bunch of parameters here that we consent for Jiko ko. But we will leave values for most parameters is default. But the values that were more interested in are the threshold values here. So to keep things simple, we will set the bill to be successful if the method code coverage hits the threshold at 75% and above. So if we leave percentage class here to be zero were telling Jake Coco that any percentage of class coverage is acceptable to set the bill to be successful amongst other thresholds we can set. We also set the bill to be unstable if the method code coverages between the threshold of 50% and 75% below that 50% the build fails. And if the code coverage percentage difference, which is also called the Delta thresholds in any of the metrics like the line coverage branch coverage, etcetera between the last successful build and the current build is 40% or more, we fail the build. You can click on the question marks here to get more information on what the thresholds mean. We must also take thes two check boxes. So once we have these values in place, we click on the generate pipeline script button that will give us the Jiko Ko step line here and we copy the generated script going back to configure before we add in the GIA Coca Line, we need to disable the Jiko Ko Report publisher within the with maven block. This is so that we do not want to cocoa to process the code coverage twice once by the with maven block and another time by the Jiko Ko step. Now we add in the Jiko Ko step line we copied just now, Let's have one last look. Let's save a job running the build once again. We currently have 100% test coverage, and these are the thresholds we have set here. Overall coverage is 100% and that is all above the max method. Coverage of 75% and minimum method coverage of 50% min Max Thresholds check is successful. We see the current Delta values here, and also what we have said here in the results of the Delta Thresholds check is successful , since we currently have 100% test coverage. So we will comment out one test case which will bring down our code coverage. Let's comment out the multiple test case, committing the code and pushing to Master Branch. Let's rerun the Jenkins job. Looking at what you coco plug in prints out. Overall coverage has dropped. Method coverage is 80 but still above max Method coverage of 75%. So we're good here and also men. Max Thresholds results is showing success. Delta thresholds we have set out at 40 and the actual Delta values are a 20% which is lower than the 40% that we have sat. And it says here that results of down to thresholds check is successful. Okay, so let's continue to decrease the number of test cases by one committing the file and pushing to Master Branch rebuilding the job. You can see that in overall coverage Methodist 60 which is below 75 and Min Max thresholds result is unstable. Delta coverage is still around 20% which is well below 40%. Results of down to thresholds check is still success. Ultimately, the build status is unstable. Let's continue to reduce the number of test cases rebuilding the job. You can see that in overall coverage. Methodist 40 which is below minimum method, coverage of 50% and Min Max thresholds result. His failure. Delta coverage is still around 20% which is below 40%. Results of down to thresholds Check his success ultimately, the build statuses failure. Now we want to show you how we can get the build to fail based on the Delta coverage thresholds. Do not forget. We have said that if the code coverage percentage difference in any of the metrics, like the line coverage branch coverage, etcetera. Between the last successful building. The current build is 40% or more. We fail the build. So we first set the build to be successful by on commenting all test cases rebuilding the job. Now that build is successful, let's now comment out to test cases rebuilding the job. Now we see that overall coverage is 60 but that's still between 50 and 75%. So the men Max thresholds Result zones table. But Delta coverage has exceeded 40% so results of down to thresholds jack is failure, and thus the build ends in failure. I hope you find this useful. Let's move on to the next lecture. 97. Bonus Lecture: Pipeline Maven Integration with SonarQube: in this lecture, we build on top of what we did in the previous lecture on J. Coca. Plug in. We will be making use of the sonar cube plug in to do integration with Sonar Cube. For those who do not know sonar, Cuba is a popular software that is used for a code quality checks as part of the build process. Now, before we begin, we already have sonar cube installed in a. You can see there are no projects here. We have also installed the Sonar Cube plug in and Jenkins and we have configured Jenkins to connect a sonar cube under Managed Jenkins Configure system. Ensure you have this checked. Give the sonar cube installation and name, and also the server. You are l which is the same i p address as the sonar cube we have installed. When you install Sonar Cube, you will be given authentication token which you put in here and save the configuration. Once we have everything in place, let's now create a Jenkins job. - We're using the same example as we did in the GIA Coca lecture, but we have get ur l pointing to the simple Java project with Sonar Cube get project. The code project is found here, and it's pretty much the same as the Coca Project. But the package name has been changed to include Sonar Cube, and there are no changes to the palm dot xml. We're still using Maven 352 and we're using the with sonar Q B N V Step. The name here is the same as what you have specified and Jenkins manage configure inside the step we call Envy and Sonar Zone. Our this will connect to the Sonar Cube server to scan for code quality. Let's even run a job once the build has finished. Let us search for the link that will take us to the sonar cube page for this project. From here we see that we have 100% code coverage, zero bugs and vulnerabilities. No technical data and codes. Males, our quality gate is past status. So what is a quality gate? It's basically a set of conditions that we have set to indicate If our code is production ready, let's add in a bug in the vulnerability in the Java code on purpose to see how sonar Cuba will process it. We have already imported the code into Eclipse. And going into the calculator class, we added a bug. Here we will need to update the expected value in our A test case so that it passes as the expected value has changed. Going back to the calculator class, we want to add in a vulnerability here. Let's commit the code publishing to get hub, rebuild the job. - The builder's successful. Now we refresh the sonar cube page, and we see that there is now one bug and vulnerability reported. Our quality gate has failed, but however, our build has still passed. So how do we make the bill fail If our quality gate fails? Let's go back to configure. Here we have created another stage called Quality Gate, where we have a wait for quality gate step. What this does is it waits for Sonar Cube to notify Jenkins on the results of the quality gate. There is a time out step in closing it, just in case it takes too long for Sonar Cube to notify Jenkins. And the stage can just exit out after one minute if the quality gate returns. Status is not okay. We fail. The Jenkins job. In order for Sonar Cube to inform Jenkins on the status of the quality gate, it needs to know how to connect to Jenkins. You need to go to Sonar Cube adminstration configuration Web hooks put in the name and Jenkins U R L is such ensure that it ends with Sonar Cube Web Hook. This is how Sonar Cube notifies Jenkins of the quality gate status going back to Jenkins. Let's now save and run a job going by the console. You can see that the time out is set to one minute and Jenkins checking the status of the Sonar Cube task on my Sonar Cube server. The task progresses from pending to success, and Jenkins is notified that the quality gate result is error and the build fails. Now let's remove all bugs and vulnerabilities, commit the code and pushing it to get hub, rerunning the build now that build passes when the quality gate has passed. Going back to Sonar Cube quality gate has passed and everything is looking good. I hope you find this useful. Let's move on to the next lecture 98. Bonus Lecture: Triggering and Passing Parameters Between Jobs: In this lecture, we will be covering how we can trigger downstream jobs from apparent job to child jobs in pipeline script. And how did past data between them we will be making use of the build step. Let's first create a parent job here . We have called the build step to execute a downstream job called Build Step Child Job one which has not been created yet. We specify a string parameter called Deploy E N V with a value of development envy. The code that is commented out is an alternative syntax of specifying a string parameter. We shall take a look at that later. There are many types of parameters you can pass to the downstream child jobs. Feel free to experiment with the different parameter types. Let's save a job. Let's now create the downstream child job. - Take note that we need to parameter rise the child job or else the parent job will not be able to pass state or to it. We have specified the same variable called deploy e N V parameter here in the child job. In the build stage, we can either reference to the deploy e n v parameter using Baram stopped employees envy or just deploy envy. Let's save and build the child job one to initialize it first. It will end with an error, but that's OK. Let us just refresh the page. Now take note that the build now link is now build with parameters. Let's now build The parent job now is the parent job is building. We can also see that the child job has been kicked off. Then it has managed to print out the deploy e N V parameter value. Going back to the parent job. You can also see from the console that the parent job is scheduling and building the child job one going back into configure. I want to use the alternative syntax for the string parameter. Let's save and run the job again. You can see that the behavior of apparent job is same as before. I would now also like to show you how you can use pipelines syntax to generate the bill, job script, clicking on the pipeline Syntax link, Select Bill job from the drop down list and put in the child job name, which in our case, is build Step child Job one and as soon as you do that, your parameter appears and you can put in a value in there. Click on generate pipeline script, and you will get the sample script to use. Next, we will demonstrate how to use the optional parameter propagate. This is an optional parameter that causes the parent job to fail if the child job fails. If the value is true, let's update the child job one to fail. Going into configure Here we have sent the result of the current build to fail, saving the job and going back to parent job. - We update the script to include the propagate parameter, which is set to true. We assigned the result of the build step to a variable called Bill Job Return Value when we echo the result of the child build. Now let's save and run the job. Going into the console, we see the child job. One has failed and also caused the parent job to fail. But however, we do not see the echo line printed anywhere. The parent job failed in the script just ended. Now let's change the propagate parameter to false Let's now rerun the job so as you can see from the console. The parent job is successfully, even though the child job is not and were able to print out the build status of the child job using the result Property of the bill. Job Return Value variable. What we can potentially do with this variable is to fail the parent job if we wanted to by using an if statement. But it's up to you to do what fits your situation. The next thing I wanted to demonstrate is the weight and quiet period optional parameters. It's a bit hard to showcase the behavior of quiet period, unless you want to wait for a long time to demonstrate the quiet period in action. But I will just put it in here anyways. As an example, the weight parameter tells the parent job to wait for it to finish before executing the following code. Let's see this in action. Going into the configure section of the parent job, - we update the script, and now we have to build jobs. We have yet to create the second bill job. We have set the quiet period to five seconds and set wait to True for both jobs. Let's save the job and go into child job. One where we make child job one to sleep for five seconds. - Let's save the job first. Now let's create child job, too. - Child job, too, is essentially the same as child Job one, but it's just that the Echo text is printing out child job, too. Let's save and build the child job to to initialize. At first it will end with an error, but that's OK. Refreshing the page. Take note that the build now link is now build with parameters. Okay, so let's start the parent job. Now. You can see the child job. One has kicked off, but there is no new child job to build. Yet. Once child job one has finished child job two kicks off. You can see that there is a new build for child job one and also a new build for child job , too. Now let's set the weight parameter to false to see what happens, saving the parent job and kicking off the build. We now see both Child job one and two are scheduled at about the same time, but the parent job does not wait for them to finish before completing successfully. you can see that there is a new build for child job one and also a new build for child job , too. I hope you find this useful. Let's move on to the next lecture. 99. Bonus Lecture: Lockable Resources: in this lecture, we take a look at the lockable resource is plug in, which will let us do resource locking amongst competing builds. Resource locking does not mean we're actually locking up the real resource. It's a logical resource that we define in Jenkins that represents the actual resource, which is used by the build examples being printers, computers, etcetera. Before we create any bill jobs, let's go into Managed Jenkins configure system. Lockable resource is manager here to define a resource, we give it a name. Description. Field, as the name suggests, allows you to describe your resource. Labels are meant to group. Resource is together. One or more resource is can have the same label which will allow us to lock. Groups of resource is using a single label. We shall take a look at that later reserved by text. Field is used for locking up in resource so that no other bills will have access to it until the text field is clear. We shall also take a look at that later. Let's create a single resource creatively called resource one. We now save the resource and let's take a look at a single resource locking example. Creating the first job with the first job. We lock resource one and then print an echo statement out to the console on sleep for five seconds. We wrap the entire script in a time stamps block so that we can see the timings of what is printed out on the console, saving the first job in creating the second job with the second job. It's essentially the same as the first job, but without the sleep step. Let's save a job now. What we're going to do is to kick off job one, followed by job, too. - So going by job one console, we see that it has locked up resource one and gone to sleep. Going over to job, too. See that job, too? Is waiting for a resource one and finally managing to lock onto it after Job one has released it when John One has finished releasing Resource one at time 14 53 and 52 seconds job to managed to lock onto it at the same time. Now let's take a look at how we can lock Resource is by labels. Let's create a second and third resource we label resource to and Resource three under the same label. Resource is 23 Now let's save the lockable resource is configuration. We now create a job that will lock up resource to and that it also sleeps for five seconds, and we now create another job that will want to lock up. Resource is 23 Note the use of the label parameter in the lock step. We have specified all resource is that have the label resource is 23 to be locked before proceeding. Please also note that you can use only either the label or resource parameter, but not both. Let's now say the job. So in summary, what we have now is a job that will lock up resource to and sleeps for five seconds in another job that wants to lock up resource to in resource three. Let's run lockstep resource to and now we run lockstep. Resource is 23 bill job. Looking at the console of lockstep resource to build job, we see that resource to has been locked up in lockstep. Resource is 23 Bill Job has managed to secure a resource three but waiting for resource to to be made available going by the correct amount number, which is to now resource to is released a time. 14 58 and eight seconds and lock step Resource is 23 Bill Job has secured resource to a time 14 58 and eight seconds and executes the downstream code. Now we want to demonstrate how to use the quantity parameter that is used together with the label parameter. Where we can specify the minimum number of resource is to lock before executing downstream code. Going back to lockstep resource is 23 bill job. We now specify the quantity of the lockstep to be one, which will require the lockstep to lock onto resource to a resource. Three. Let's now run lockstep resource to build job and now we run lockstep Resource is 23 bill job. - As you can see lockstep Resource is 23 build Job only needs to lock one resource, which in this case is resource three before executing downstream code. Now let's take a look at the inverse precedence parameter by default. This parameter is false, which means that builds will be given the locks in the order they requested. Let's see this in action. We will be creating another bill job lockstep resource one. See that will compete to lock up resource one and then sleep for five seconds. We will now update Lockstep Resource one. Be billed job with the same pipeline script. Lockstep Resource one. A Pipeline script is already the same as lockstep. Resource one. See Pipeline script To demonstrate how inverse presidents equals two false works. We will triggering of lockstep Resource one. A Bill job followed by lockstep Resource one. Be in lockstep Resource one. See Bill Jobs from the console. You can see that lockstep Resource one. A Bill job has acquired. Resource one first at 16 06 and 59 seconds. Release the locket 16 07 and four seconds. At which time? Lockstep Resource one B bill job locks onto it. Released it at 16 07 and nine seconds and then the lockstep resource one. See Bill Job locks onto it. Now let's set the inverse precedence to be true in Lockstep Resource one. A bill job triggering all three bill jobs in the same order again. - Lockstep resource one. A bill job acquires the lock First released it at 16 09 and five seconds, but lock on resource one was not acquired by lockstep Resource one b bill job, but by lockstep resource one. See bill job. Because in verse, presidents parameter is set to true, Which means that newest build to request the lock will be granted in first after lockstep resource one. See Bill Job releases the locket 16 09 and 10 seconds, then lockstep resource one be billed Job gets the lock. Another thing that I want to show you is the lockable resource is link hear clicking. It will show you what resource is locked by whom. We will also make use of this screen when we demonstrate how they're reserved by text. Field works going back into Managed Jenkins configure system We now want to reserve resource one by putting in some text and reserved by text. Field it going to be any text, but it should be meaningful. Let's put John in here, so once we save it, we go back to the lockable resource is dashboard and we see it has been reserved by John So all other builds will not have access to it until the reserve is released. Let's now kickoff Lockstep Resource one a and lock step resource one B. - You can see from the console that the two builds air waiting for resource one to be released. Going back to the lockable resource is dashboard. Let's now on reserve resource one using the unreserved button and you can see that resource one is immediately taken by lockstep. Resource one. A build for and waiting for a while longer. We see that lockstep resource one. Be build four has locked up resource one. I hope you find this useful. Let's move on to the next lecture. 100. Bonus Lecture: Extended Choice Parameter: In this lecture, we look at how we can create a multi select check box as an input parameter to the bill, just like how it is shown here, where we can select multiple options and assign it to a single variable. Take note that this is unlike the choice parameter that we have covered in previous lectures, where we can only choose one option as a demonstration. Let's do a build. We have already selected some arbitrary options and let's click on the build button going to the console. We see that the options that we have selected as printed out we did not print out the values of the single choice parameter. Is there not the focus of this lecture? This multi select functionality is provided by the extended choice parameter plug in Going into managed Jenkins plug and manager. We see that we already have the extended choice parameter plug in installed. Let's create a new job to see how we can create this multi select parameter with this example. We're using scripted pipeline. Now, before we go any further, let me just show you the get home page of the extended choice parameter plug in in my opinion, the documentation of the extended choice parameter plugging could be better. So we need to take a look at the source code of the plug in to see how we can create this multi select parameter. Looking at the extended choice parameter definition Java file. One of the things that I wanted to point out to you is that the extended choice parameter plug in does not only create multi select option. Looking at the constants of the Java file, we can see that we have the option of creating other types of options, like single select option check boxes, radio boxes, etcetera. We will be referencing this extended choice parameter definition Java file as we walk through what is going on in the pipeline script going back to the pipeline script. Let's examine line by line what is happening here. So the first line is an import of the extended choice parameter definition class. It is the class we saw just now in the notes section. We create a new instance of the extended choice parameter definition class inside the property step. As you can see, there are many constructor arguments, so we will go back again to the job I file and we search for public extended choice parameter definition. You can see what the constructor arguments are. We will be switching back and forth between the pipeline script and this Java source code to see how the constructor arguments are mapped. So the first argument, his name and we have color of cars, the name of the multi select option. We have types at his PT check box that is the name of the constant at the top of the job. The file next we have value is the third argument. We have set a comma, separated string of values red, blue, yellow and green. We leave the subsequent arguments is empty strings for now as we are not using them and we go all the way down to description property value where we set the description of the multi select values that we specified above which are red, blue, yellow, green. This is what's going to appear to the user. We have sent the Save Jason parameter to file unquote value to fall, says we do not need them. We have set visible item counted for so that we will not have a scroll bar beside the multi select box. If our number of options is big, then visible item counts set to four will show to the user only four items at a time, with the scroll bar at the side for the user to view the other options. The description argument allows us to write a short description of what this multi select option is about, and the multi select A limiter argument allows us to specify what the delimit ER is for the property values. In this case, we have said it to a dash so that the values of the options that we have selected will be delimited by this dash. At the end of the script, we print out what the user has selected. Note that the variable name we're using is the same as the name we have specified in the first parameter to the constructor. Let's save and run a job. As per previous lectures on parameters, we will always need to run. The build wants to initialize it. After that, we refresh the build page and we see that we have to build with parameters link. We click on that and we see that the multi select option is available to us. We select two options and click on the build button going into the console. You can see that the values of the options we selected is being printed out, and they are delimited by the delimit er we specified earlier, which is a dash going back into configure. You can see that we have additional sections here in the bill job that have been created with the values that we have specified as constructor arguments to the extended choice parameter definition class in our pipeline script, feel free to explore the other options. That extended choice parameter definition gives you please let me know if you want me to do more lectures on this plug in. I hope you find this useful. Let's move on to the next lecture.