Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add transcripts with minor cleanup #7530

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions content/doc/book/using/working-with-projects.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,12 @@ Darin Pope provides a summary of the differences between Pipeline projects and f
.Comparing Pipeline and freestyle projects
video::IOUm1lw7F58[youtube,width=800,height=420]

.Click to reveal the transcript
[%collapsible]
====
If you've been around Jenkins for any amount of time, you might remember the time before pipeline existed. And in fact, you might even still have a few freestyle jobs running on your controller. But have you ever taken the time to really understand the difference between freestyle and pipeline? In this video, we're going to demonstrate one of the reasons why you might want to go ahead and migrate those freestyle jobs over to pipeline. Here's today starting point. I have a Jenkins LTS controller version 2.319.2 and attached to this controller, I have a Linux based agent. Now what we're going to be doing is we're going to be creating two jobs, a set of freestyle jobs that is going to look like and act like a single pipeline job. So let's get started on our freestyle jobs. I'm going to say new item. I'm going to call this F1, freestyle project, and click OK. Now these are going to be very contrived in simple examples, but I've seen these over time to where people have made really complex freestyle jobs and chained them together to end up with what looks like an X-like a pipeline, but with some very, very different types of management. So let's take a look at how we're building this one out. We're going to add a build step execute shell because we have a Linux based agent and the command is going to be echo Hello 1. I'm going to click on save. Let's go back and create another job called F2 freestyle click OK. For this one, we're also going to add a build step and I'm going to say sleep 60 and click on save. And finally, I'm going to create an F3 freestyle, where my step is now going to be echo, hello, two. Okay. So we've created three different freestyle jobs. The first one is saying echo, hello, one. The second one is sleep 60. and then the third one is going to be echo hello too. Now I want to go back and verify my F1 here real quick and make sure that everything is set up correctly. And what we're doing is echo hello one, yes I did forget to put quotes around that, not a big deal but we'll save it. Now what I want to do is I want to link these three together. And the way that I need to do that is I need to go over to F2 and I'm going to click on "Configure" and I'm going to say under "Build Triggers" "Build after other projects are built" so I want this one to follow F1 and I'm just going to do this as a basic, I'm not going to get into all the different trigger types, just a very simple basic F1. I'm going to click on save. Let's go down to F3 and I want F3 to follow F2. Are you seeing some of the pain points here? I'm having to go through and go into the UI and make all of these changes if I'm using freestyle. But again, until pipeline existed, we didn't have a choice. So let's go back and take a look at F1. And what we're going to see a downstream project for F1 is F2, which is what we would expect. we're going to move from f1 into f2. If we click into f2, which we can do here, thankfully, project f2, we can see the upstream is f1 and the downstream is f3. And if we click on f3, we can see that the upstream is f2. So we have it all wired up, f1 to f2 to f3. Now what do we do? Well let's go ahead and just run this set of jobs. It's not a single job, but a set of jobs to see what happens. When we When we click on build now for F1, when it starts up, it's an immediate echo hello one, no big deal, then it's triggering a new build of F2. If I click into F2, I can see that F2 is running and it's in a sleep 60, we'll fast forward through this. And now it's triggered off to do F3 and when we take a look at F3, once it goes ahead and starts, what we'll see here is that F3 completed and it said echo hello too. Hello, too. So F1 triggered F2 that triggered F3. Now sure, I could have created a single free style job with three steps, but I wanted to show you how you would have to wire jobs together in order to do these things prior to pipeline existing. So now let's go over and create a pipeline job that does the same thing, but now you're going to say, okay, you're not comparing apples to apples. This is really apples to oranges. Yes, I agree. I get it. I understand. But I'm trying to show you when pipeline first came out, what the purpose of it was. It was to help combine the separate freestyle jobs into a definition of a job that could be managed as code. So let's go ahead and go to pipeline and let's paste in my pipeline. And we can see here that I have three different stages. different stages. These stages represented each of the different freestyle jobs that we saw previously. So I have an echo hello one, a sleep 60 and a echo hello two. What's going click on save and then click on bill now. And what we'll do is we'll take a look at the log as it starts up. But then we'll fast forward through the rest of this. And as this finished up, you can see here that the output from our single pipeline job represents the output of each of the three different freestyle jobs that we had. Hello, one, we slept for 60 seconds and then echo hello to. But now I want to show you one of the big differences between freestyle and pipeline. And that is durability. And what do I mean by durability? In this case, what durability means is in the case of a restart of a Jenkins controller. Any pipeline jobs that were already running once that controller comes back up will automatically start back up from where they left off. However, freestyle jobs, don't do that. So let's see the example. I'm going to go ahead and go back up to the top and I'm going to click on F1 and build now and P1 and build now. If we're going to take a look at the output for both P1 and F2, what we're going to see, we'll take a look at P1 first. We can see that we're in our sleep 60 and if we go over to F2, we can also see that we're in our sleep 60 here. So what I'm going to do is I am going to go ahead and do a kill of the process that's running our Jenkins controller. So I'm just going to do a kill - 9.55. Okay, I forgot to do so to do so to kill - 9.51.55. All right, so now I've killed the process. In fact, we can see that if we go back in here to Jenkins, it's just setting there. There's nothing going on. So let's go ahead and restart, or Jenkins controller. And this will take just a few moments to start back up. And as this starts back up, what we're going to see, once we log back in, is that the freestyle jobs are no longer running and our pipeline job will have picked up from where it left off and then finish up. So we can see here that P1 is now starting back up. We don't see any activity on F1 or F2, but if we take a look at the output of job number 2, which was running when we killed the process, we can see that we were in a sleep 60 and then we can see that we did a resuming build after a Jenkins restart, it finished waiting, we waited for everything to finish up, and then it went ahead, picked up and continued on in ran Hello2. If we take a look at our F2, we were into number 2, but we killed it during the time that 2 was running. We can also see in F3 that it never even got to that stage because after the restart, freestyle jobs have no way of knowing what was running before the shutdown. Down in the description of this video is a link to this page that explains why pipeline. We went through one of these in this video and that is the first one durability. In previous videos, I've also gone through possible and versatile. Look down in the description and you'll see some links off to those videos as well. If you have any questions or comments, you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you've been around Jenkins for any amount of time, you might remember the time before pipeline existed. And in fact, you might even still have a few freestyle jobs running on your controller. But have you ever taken the time to really understand the difference between freestyle and pipeline? In this video, we're going to demonstrate one of the reasons why you might want to go ahead and migrate those freestyle jobs over to pipeline. Here's today starting point. I have a Jenkins LTS controller version 2.319.2 and attached to this controller, I have a Linux based agent. Now what we're going to be doing is we're going to be creating two jobs, a set of freestyle jobs that is going to look like and act like a single pipeline job. So let's get started on our freestyle jobs. I'm going to say new item. I'm going to call this F1, freestyle project, and click OK. Now these are going to be very contrived in simple examples, but I've seen these over time to where people have made really complex freestyle jobs and chained them together to end up with what looks like an X-like a pipeline, but with some very, very different types of management. So let's take a look at how we're building this one out. We're going to add a build step execute shell because we have a Linux based agent and the command is going to be echo Hello 1. I'm going to click on save. Let's go back and create another job called F2 freestyle click OK. For this one, we're also going to add a build step and I'm going to say sleep 60 and click on save. And finally, I'm going to create an F3 freestyle, where my step is now going to be echo, hello, two. Okay. So we've created three different freestyle jobs. The first one is saying echo, hello, one. The second one is sleep 60. and then the third one is going to be echo hello too. Now I want to go back and verify my F1 here real quick and make sure that everything is set up correctly. And what we're doing is echo hello one, yes I did forget to put quotes around that, not a big deal but we'll save it. Now what I want to do is I want to link these three together. And the way that I need to do that is I need to go over to F2 and I'm going to click on "Configure" and I'm going to say under "Build Triggers" "Build after other projects are built" so I want this one to follow F1 and I'm just going to do this as a basic, I'm not going to get into all the different trigger types, just a very simple basic F1. I'm going to click on save. Let's go down to F3 and I want F3 to follow F2. Are you seeing some of the pain points here? I'm having to go through and go into the UI and make all of these changes if I'm using freestyle. But again, until pipeline existed, we didn't have a choice. So let's go back and take a look at F1. And what we're going to see a downstream project for F1 is F2, which is what we would expect. we're going to move from f1 into f2. If we click into f2, which we can do here, thankfully, project f2, we can see the upstream is f1 and the downstream is f3. And if we click on f3, we can see that the upstream is f2. So we have it all wired up, f1 to f2 to f3. Now what do we do? Well let's go ahead and just run this set of jobs. It's not a single job, but a set of jobs to see what happens. When we When we click on build now for F1, when it starts up, it's an immediate echo hello one, no big deal, then it's triggering a new build of F2. If I click into F2, I can see that F2 is running and it's in a sleep 60, we'll fast forward through this. And now it's triggered off to do F3 and when we take a look at F3, once it goes ahead and starts, what we'll see here is that F3 completed and it said echo hello too. Hello, too. So F1 triggered F2 that triggered F3. Now sure, I could have created a single free style job with three steps, but I wanted to show you how you would have to wire jobs together in order to do these things prior to pipeline existing. So now let's go over and create a pipeline job that does the same thing, but now you're going to say, okay, you're not comparing apples to apples. This is really apples to oranges. Yes, I agree. I get it. I understand. But I'm trying to show you when pipeline first came out, what the purpose of it was. It was to help combine the separate freestyle jobs into a definition of a job that could be managed as code. So let's go ahead and go to pipeline and let's paste in my pipeline. And we can see here that I have three different stages. different stages. These stages represented each of the different freestyle jobs that we saw previously. So I have an echo hello one, a sleep 60 and a echo hello two. What's going click on save and then click on bill now. And what we'll do is we'll take a look at the log as it starts up. But then we'll fast forward through the rest of this. And as this finished up, you can see here that the output from our single pipeline job represents the output of each of the three different freestyle jobs that we had. Hello, one, we slept for 60 seconds and then echo hello to. But now I want to show you one of the big differences between freestyle and pipeline. And that is durability. And what do I mean by durability? In this case, what durability means is in the case of a restart of a Jenkins controller. Any pipeline jobs that were already running once that controller comes back up will automatically start back up from where they left off. However, freestyle jobs, don't do that. So let's see the example. I'm going to go ahead and go back up to the top and I'm going to click on F1 and build now and P1 and build now. If we're going to take a look at the output for both P1 and F2, what we're going to see, we'll take a look at P1 first. We can see that we're in our sleep 60 and if we go over to F2, we can also see that we're in our sleep 60 here. So what I'm going to do is I am going to go ahead and do a kill of the process that's running our Jenkins controller. So I'm just going to do a kill - 9.55. Okay, I forgot to do so to do so to kill - 9.51.55. All right, so now I've killed the process. In fact, we can see that if we go back in here to Jenkins, it's just setting there. There's nothing going on. So let's go ahead and restart, or Jenkins controller. And this will take just a few moments to start back up. And as this starts back up, what we're going to see, once we log back in, is that the freestyle jobs are no longer running and our pipeline job will have picked up from where it left off and then finish up. So we can see here that P1 is now starting back up. We don't see any activity on F1 or F2, but if we take a look at the output of job number 2, which was running when we killed the process, we can see that we were in a sleep 60 and then we can see that we did a resuming build after a Jenkins restart, it finished waiting, we waited for everything to finish up, and then it went ahead, picked up and continued on in ran Hello2. If we take a look at our F2, we were into number 2, but we killed it during the time that 2 was running. We can also see in F3 that it never even got to that stage because after the restart, freestyle jobs have no way of knowing what was running before the shutdown. Down in the description of this video is a link to this page that explains why pipeline. We went through one of these in this video and that is the first one durability. In previous videos, I've also gone through possible and versatile. Look down in the description and you'll see some links off to those videos as well. If you have any questions or comments, you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video.
If you've been around Jenkins for any amount of time, you might remember the time before Pipeline existed.
In fact, you might even still have a few freestyle jobs running on your controller.
Have you ever taken the time to really understand the difference between freestyle and Pipeline?
In this video, we're going to demonstrate one of the reasons why you might want to go ahead and migrate those freestyle jobs over to Pipeline.
Here's today's starting point; I have a Jenkins LTS controller version 2.319.2 and attached to this controller, I have a Linux based agent.
Now, what we're going to be doing is we're going to be creating two jobs: a set of freestyle jobs that is going to look like and act like a single Pipeline job.
So let's get started on our freestyle jobs.
I'm going to select *New Item*, and I'm going to call this F1, select Freestyle project, and click OK.
Now, these are going to be very contrived and simple examples, but I've seen these over time to where people have made really complex freestyle jobs and chained them together, to end up with what looks like an X-like a Pipeline, but with some very, very different types of management.
So, let's take a look at how we're building this one out.
We're going to add a `build` step, select execute shell, because we have a Linux based agent, and the command is going to be `echo 'hello1'`.
I'm going to click on save.
Let's go back and create another job called F2, select freestyle, and click OK.
For this one, we're also going to add a `build` step and I'm going to say `sleep 60` and click save.
Finally, I'm going to create another job, call it F3 and select freestyle.
Here my step is now going to be `echo 'hello2'`.
So we've created three different freestyle jobs.
The first one is saying `echo 'hello1'`, the second one is `sleep 60`, then the third one is going to be `echo 'hello2'`.
Now I want to go back and verify my F1 here real quick and make sure that everything is set up correctly.
What we're doing is `echo 'hello1'`.
Now what I want to do is I want to link these three together.
The way that I need to do that is, I need to go over to F2 and I'm going to click on *Configure* and I'm going to say, under *Build Triggers*, *Build after other projects are built* so I want this one to follow F1 and I'm just going to do this as a basic, I'm not going to get into all the different trigger types, just a very simple basic F1.
I'm going to click on save.
Let's go down to F3 and I want F3 to follow F2.
Are you seeing some of the pain points here?
I'm having to go through and go into the UI and make all of these changes if I'm using freestyle.
But again, until Pipeline existed, we didn't have a choice.
So let's go back and take a look at F1.
What we're going to see a downstream project for F1 is F2, which is what we would expect.
We're going to move from F1 into F2.
If we click into f2, which we can do here, project F2, we can see the upstream is F1 and the downstream is F3.
If we click on F3, we can see that the upstream is F2.
So, we have it all wired up F1 to F2 to F3.
Now what do we do?
Well let's go ahead and just run this set of jobs.
It's not a single job, but a set of jobs, to see what happens.
When we click on build now for F1, when it starts up, it's an immediate `echo 'hello1'`, no big deal, then it's triggering a new build of F2.
If I click into F2, I can see that F2 is running and it's in a `sleep 60`, we'll fast forward through this.
Now it's triggered off to do F3 and when we take a look at F3, once it goes ahead and starts, what we'll see here is that F3 completed and it said `echo 'hello2'`.
So F1 triggered F2 that triggered F3.
Now sure, I could have created a single freestyle job with three steps, but I wanted to show you how you would have to wire jobs together in order to do these things prior to Pipeline existing.
So now, let's go over and create a Pipeline job that does the same thing, but now you're going to say, okay, you're not comparing apples to apples.
This is really apples to oranges.
Yes, I agree.
I get it, I understand, but I'm trying to show you when Pipeline first came out, what the purpose of it was.
It was to help combine the separate freestyle jobs into a definition of a job that could be managed as code.
So let's go ahead and go to Pipeline and let's paste in my Pipeline.
We can see here that I have three different stages.
These stages represented each of the different freestyle jobs that we saw previously.
So I have an `echo 'hello1'`, a `sleep 60`, and an `echo 'hello2'`.
Lets go and click on save and then click on build now.
What we'll do, is we'll take a look at the log as it starts up.
Then we'll fast forward through the rest of this.
As this finished up, you can see here that the output from our single Pipeline job represents the output of each of the three different freestyle jobs that we had.
`Hello1`, we slept for 60 seconds and then `echo 'hello2'`.
But now I want to show you one of the big differences between freestyle and Pipeline, and that is durability.
What do I mean by durability?
In this case, what durability means is in the case of a restart of a Jenkins controller, any Pipeline jobs that were already running, once that controller comes back up will automatically start back up from where they left off.
However, freestyle jobs, don't do that.
So let's see the example.
I'm going to go ahead and go back up to the top and I'm going to click on F1 and build now, and P1 and build now.
If we're going to take a look at the output for both P1 and F2, what we're going to see, we'll take a look at P1 first.
We can see that we're in our `sleep 60` and if we go over to F2, we can also see that we're in our `sleep 60` here.
So what I'm going to do is I am going to go ahead and do a `kill` of the process that's running our Jenkins controller.
So I'm just going to do a `kill - 9 5155`.
Okay, I forgot to do `sudo`, `sudo kill - 9 5155`.
All right, so now I've killed the process.
In fact, we can see that if we go back in here to Jenkins, it's just sitting there, there's nothing going on.
So let's go ahead and restart our Jenkins controller.
This will take just a few moments to start back up.
As this starts back up, what we're going to see, once we log back in, is that the freestyle jobs are no longer running and our Pipeline job will have picked up from where it left off and then finish up.
So we can see here that P1 is now starting back up.
We don't see any activity on F1 or F2, but if we take a look at the output of job number 2, which was running when we killed the process, we can see that we were in a `sleep 60` and then we can see that we did a resuming build after a Jenkins restart, it finished waiting, we waited for everything to finish up, and then it went ahead, picked up, and continued on in ran `hello2`.
If we take a look at our F2, we were into number 2, but we killed it during the time that 2 was running.
We can also see in F3, that it never even got to that stage because after the restart, freestyle jobs have no way of knowing what was running before the shutdown.
Down in the description of this video is a link to this page that explains why Pipeline.
We went through one of these in this video and that is the first one durability.
In previous videos, I've also gone through possible and versatile.
Look down in the description and you'll see some links off to those videos as well.
If you have any questions or comments, you can reach out to us on Twitter @CloudBees.
If this video was helpful to you, give us a thumbs up.
If you haven't subscribed to CloudBeesTV yet, why not?
Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV.
Thanks for watching, and we will see you in the next video.

Revised transcript with punctuation, paragraph breaks, capitalization, and formatting.

====

== Copying projects

Copy an existing project by clicking the "New Item" link on the side panel.
Expand All @@ -38,6 +44,12 @@ The existing project will be copied to a new project with the name that was ente
.Copy a project
video::MNzNPCJJqaI[youtube,width=800,height=420]

.Click to reveal the transcript
[%collapsible]
====
How to clone a Jenkins job. Here's today's starting point. I have a Jenkins LTS controller version 2.346.3. And on this controller, already have a sample job setup. Now the sample job is just a very simple test pipeline. In fact, the name even says it. If we take a look at the configuration, no options are checked, and we have a basic pipeline script already defined within the script block. So let's go back up to dashboard and let's create a new item. So we're wanting to clone test pipeline. So in this case, I'm going to say test pipeline -2. But instead of picking pipeline, I'm going to scroll to the bottom and I'm going to say copy from. I'm going to start typing here. So I'm going to say "T" and it automatically finds the test-pipeline for me. So I'll select that and click on "OK". Now, you'll notice up in the breadcrumb, we now have test pipeline 2. But if we go down into the script block, you can see that the job definition is here. So let's make a small change to this. I'll say hello world to, okay. Let's click on save. And now let's click on build now to make sure it actually works. And as it completes, we can see that it finished up and hello world to was output. And let's go back up to our dashboard, and we can see at the root of our Jenkins controller, we have two jobs, test dash pipeline and test dash pipeline dash two. Now, what if I wanted to do this from the command line? So let's go ahead and go over into Managed Jenkins, scroll down to the bottom and click on Jenkins CLI. If you've never downloaded the Jenkins CLI before, you can download it right here from the top of the page. And the command that we're gonna be wanting to run is Copy Job. And if you take a look at the syntax for Copy Job, we'll say Copy Job, we'll give it the source, and then we'll give it the destination. So the existing job and what the new job is. Let's go over to our command prompt, and let's set up a few environment variables. The first environment variable that we're gonna set up is Jenkins's user ID, and we're setting it to admin, because that's the user that I already have set up on this controller. The second environment variable that we're setting is Jenkins_API_token. And this is the token associated with the admin user. If you click on admin and go to configure, you'll see that there's already an API token here, and the value of this token is what we have in our shell. And finally, we're going to set up our Jenkins URL, which is the URL for our server, which is Jenkins' colon AD80. Now let's go ahead and run our copy job command. So we'll say java-jar, jenkins-cli.jar, copy job. We're going to copy from our original job, which is test-pipeline. And the new name is going to be test-pipeline-3. So when we hit enter, it's going to copy that job. But we don't see anything in the command prompt. So let's go back over to our dashboard. And you'll see now that we have test-pipeline-3. Now, unlike when we did the copy within the UI, where we were able to make changes before we clicked on Save. Here, it just copied from our source pipeline in this case over to our destination pipeline, which is test pipeline three. So I can click into this, click on Configure, make any extra changes that I want to make. In this case, I'm just going to add a three, click Save, and then click on Build Now. Now that we have test pipeline three, we've made the change, and now the output is Hello World Three. If you have any questions or comments, you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video. (upbeat music)
Copy link
Contributor

@kmartens27 kmartens27 Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
How to clone a Jenkins job. Here's today's starting point. I have a Jenkins LTS controller version 2.346.3. And on this controller, already have a sample job setup. Now the sample job is just a very simple test pipeline. In fact, the name even says it. If we take a look at the configuration, no options are checked, and we have a basic pipeline script already defined within the script block. So let's go back up to dashboard and let's create a new item. So we're wanting to clone test pipeline. So in this case, I'm going to say test pipeline -2. But instead of picking pipeline, I'm going to scroll to the bottom and I'm going to say copy from. I'm going to start typing here. So I'm going to say "T" and it automatically finds the test-pipeline for me. So I'll select that and click on "OK". Now, you'll notice up in the breadcrumb, we now have test pipeline 2. But if we go down into the script block, you can see that the job definition is here. So let's make a small change to this. I'll say hello world to, okay. Let's click on save. And now let's click on build now to make sure it actually works. And as it completes, we can see that it finished up and hello world to was output. And let's go back up to our dashboard, and we can see at the root of our Jenkins controller, we have two jobs, test dash pipeline and test dash pipeline dash two. Now, what if I wanted to do this from the command line? So let's go ahead and go over into Managed Jenkins, scroll down to the bottom and click on Jenkins CLI. If you've never downloaded the Jenkins CLI before, you can download it right here from the top of the page. And the command that we're gonna be wanting to run is Copy Job. And if you take a look at the syntax for Copy Job, we'll say Copy Job, we'll give it the source, and then we'll give it the destination. So the existing job and what the new job is. Let's go over to our command prompt, and let's set up a few environment variables. The first environment variable that we're gonna set up is Jenkins's user ID, and we're setting it to admin, because that's the user that I already have set up on this controller. The second environment variable that we're setting is Jenkins_API_token. And this is the token associated with the admin user. If you click on admin and go to configure, you'll see that there's already an API token here, and the value of this token is what we have in our shell. And finally, we're going to set up our Jenkins URL, which is the URL for our server, which is Jenkins' colon AD80. Now let's go ahead and run our copy job command. So we'll say java-jar, jenkins-cli.jar, copy job. We're going to copy from our original job, which is test-pipeline. And the new name is going to be test-pipeline-3. So when we hit enter, it's going to copy that job. But we don't see anything in the command prompt. So let's go back over to our dashboard. And you'll see now that we have test-pipeline-3. Now, unlike when we did the copy within the UI, where we were able to make changes before we clicked on Save. Here, it just copied from our source pipeline in this case over to our destination pipeline, which is test pipeline three. So I can click into this, click on Configure, make any extra changes that I want to make. In this case, I'm just going to add a three, click Save, and then click on Build Now. Now that we have test pipeline three, we've made the change, and now the output is Hello World Three. If you have any questions or comments, you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video. (upbeat music)
How to clone a Jenkins job.
Here's today's starting point: I have a Jenkins LTS controller version 2.346.3 and on this controller, I already have a sample job setup.
Now the sample job is just a very simple test Pipeline.
In fact, the name even says it.
If we take a look at the configuration, no options are checked and we have a basic Pipeline script already defined within the script block.
Let's go back up to dashboard and let's create a *new item*.
So we're wanting to clone "test-pipeline".
So in this case, I'm going to say "test-pipeline-2", but instead of picking Pipeline, I'm going to scroll to the bottom and I'm going to say copy from and I'm going to start typing here.
I'm going to say "T" and it automatically finds the "test-pipeline" for me.
So I'll select that and click on *OK*.
Now, you'll notice up in the breadcrumb, we now have "test-pipeline-2".
But if we go down into the script block, you can see that the job definition is here.
So let's make a small change to this, I'll say `'Hello World 2'` okay.
Let's click on save and now, let's click on build now to make sure it actually works.
As it completes, we can see that it finished up and `Hello World 2` was output.
Let's go back up to our dashboard, and we can see at the root of our Jenkins controller, we have two jobs, "test-pipeline" and "test-pipeline-2".
Now, what if I wanted to do this from the command line?
Let's go ahead and go over into Manage Jenkins, scroll down to the bottom and click on *Jenkins CLI*.
If you've never downloaded the Jenkins CLI before, you can download it right here from the top of the page.
The command that we're gonna be wanting to run is `copy-job`.
If you take a look at the syntax for `copy-job`, we'll say `copy-job`, we'll give it the source, and then we'll give it the destination.
So the existing job and what the new job is.
Let's go over to our command prompt, and let's set up a few environment variables.
The first environment variable that we're gonna set up is `JENKINS_USER_ID`, and we're setting it to `admin`, because that's the user that I already have set up on this controller.
The second environment variable that we're setting is `JENKINS_API_TOKEN`.
This is the token associated with the admin user.
If you click on admin and go to configure, you'll see that there's already an API token here, and the value of this token is what we have in our shell.
Finally, we're going to set up our `JENKINS_URL`, which is the URL for our server, which is `jenkins:8080`.
Now let's go ahead and run our copy job command.
So we'll say `java -jar jenkins-cli.jar copy job test-pipeline test-pipeline-3`.
We're going to copy from our original job, which is "test-pipeline".
The new name is going to be "test-pipeline-3".
So when we hit enter, it's going to copy that job, but we don't see anything in the command prompt.
Let's go back over to our dashboard and you'll see now that we have "test-pipeline-3".
Now, unlike when we did the copy within the UI, where we were able to make changes before we clicked on *Save*.
Here, it just copied from our source Pipeline in this case over to our destination Pipeline, which is "test-pipeline-3".
So I can click into this, click on *Configure*, and make any extra changes that I want to make.
In this case, I'm just going to add a three, click *Save*, and then click on *Build Now*.
Now that we have "test-pipeline-3", we've made the change, and now the output is `Hello World 3`.
If you have any questions or comments, you can reach out to us on Twitter @CloudBees.
If this video was helpful to you, give us a thumbs up.
And if you haven't subscribed to CloudBeesTV yet, why not?
Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV.
Thanks for watching, and we will see you in the next video.

====

== Renaming projects

Rename an existing project by clicking the "Rename" action on the project page.
Expand All @@ -46,10 +58,22 @@ When a job is renamed, other jobs that refer to the job by name must be updated
.Rename a project
video::zO3xnCwbv_c[youtube,width=800,height=420]

.Click to reveal the transcript
[%collapsible]
====
Rename a job in Jenkins. Here's today's starting point. I have a Jenkins controller version 2.361.2. And I already have a job predefined on this controller. Now if you look at this job, you can see it's named job 1. Not very descriptive. Let's go ahead and take a look at the job and let's figure out what it's really doing. So in this case, what we have is just a Hello World type job. Now again, this is a very contrived example, but follow me through this process. So you can think about how you might want to go ahead and name some of your jobs. So let's go back up and let's assume for a moment that I want to go ahead and name this "Hello". Well, go back to Job1 and on the left nav you'll see "Rename". So let's change Job1 to "Hello". Okay, I like that. If I take a look now, I can see Job1 has been renamed "Hello". And I can also see that my URL also is "Hello". Well, "Hello" is fine, but it's not really exactly what I want. Can you guess where I'm going next? Let's make it Hello World. So let's rename Hello to Hello Space World. When we click on Rename, we can see the pipeline as Hello Space World. But if you look up in the URL, I also see a space here. That's not really what I want. In fact, if I click into it again, that could be really hard to work with from CLIs or using Curl or WGET. So for my URL, I really want to put in a hyphen. So let's go ahead and rename our job one more time here. Let's change this to dash. I click on rename and now my pipeline is named hello-world. If I look up in my URL, it's also a hello-world. That's exactly what I wanted, but really, it's still not what I want. Now at Hello World, I'm okay with here, but looking at my dashboard, I see hello-world. Well, really what I want to show, especially when I'm on the dashboard view in this case, is I want to give this a more human-friendly name. Instead of a URL friendly name, I want to have a human friendly name. Let's go into our job and click on configure and let's scroll down to advanced. Now depending on which job that you're using, this next field, which is called display name, may show up in different places. Sometimes it will be exposed. Sometimes it will be under advanced. So in this case, what I want to have is I want to say, "Hello world from the universe." Let's click on Save. We can see here that our pipeline name now is Hello World from the universe, but our project name or our job name is still Hello Dash World. So if we take a look up in the URL, it's still Hello Dash World, but in the breadcrumb, we see the full display name that we just typed in. And in fact, when we go back to the root of our dashboard, we can see Hello World from the universe. If you have any questions or comments, you can reach out to us on Twitter at CloudBeast. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video.
Copy link
Contributor

@kmartens27 kmartens27 Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Rename a job in Jenkins. Here's today's starting point. I have a Jenkins controller version 2.361.2. And I already have a job predefined on this controller. Now if you look at this job, you can see it's named job 1. Not very descriptive. Let's go ahead and take a look at the job and let's figure out what it's really doing. So in this case, what we have is just a Hello World type job. Now again, this is a very contrived example, but follow me through this process. So you can think about how you might want to go ahead and name some of your jobs. So let's go back up and let's assume for a moment that I want to go ahead and name this "Hello". Well, go back to Job1 and on the left nav you'll see "Rename". So let's change Job1 to "Hello". Okay, I like that. If I take a look now, I can see Job1 has been renamed "Hello". And I can also see that my URL also is "Hello". Well, "Hello" is fine, but it's not really exactly what I want. Can you guess where I'm going next? Let's make it Hello World. So let's rename Hello to Hello Space World. When we click on Rename, we can see the pipeline as Hello Space World. But if you look up in the URL, I also see a space here. That's not really what I want. In fact, if I click into it again, that could be really hard to work with from CLIs or using Curl or WGET. So for my URL, I really want to put in a hyphen. So let's go ahead and rename our job one more time here. Let's change this to dash. I click on rename and now my pipeline is named hello-world. If I look up in my URL, it's also a hello-world. That's exactly what I wanted, but really, it's still not what I want. Now at Hello World, I'm okay with here, but looking at my dashboard, I see hello-world. Well, really what I want to show, especially when I'm on the dashboard view in this case, is I want to give this a more human-friendly name. Instead of a URL friendly name, I want to have a human friendly name. Let's go into our job and click on configure and let's scroll down to advanced. Now depending on which job that you're using, this next field, which is called display name, may show up in different places. Sometimes it will be exposed. Sometimes it will be under advanced. So in this case, what I want to have is I want to say, "Hello world from the universe." Let's click on Save. We can see here that our pipeline name now is Hello World from the universe, but our project name or our job name is still Hello Dash World. So if we take a look up in the URL, it's still Hello Dash World, but in the breadcrumb, we see the full display name that we just typed in. And in fact, when we go back to the root of our dashboard, we can see Hello World from the universe. If you have any questions or comments, you can reach out to us on Twitter at CloudBeast. If this video was helpful to you, give us a thumbs up. And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching, and we will see you in the next video.
Rename a job in Jenkins.
Here's today's starting point; I have a Jenkins controller version 2.361.2 and I already have a job predefined on this controller.
Now if you look at this job, you can see it's named "job1", not very descriptive.
Let's go ahead and take a look at the job and let's figure out what it's really doing.
So in this case, what we have is just a `Hello World` type job.
Now again, this is a very contrived example, but follow me through this process so you can think about how you might want to go ahead and name some of your jobs.
So let's go back up and let's assume for a moment that I want to go ahead and name this "Hello".
Well, go back to "job1" and on the left nav you'll see *Rename*.
So let's change "job1" to "hello".
Okay, I like that.
If I take a look now, I can see "job1" has been renamed "Hello", and I can also see that my URL also is `hello`.
Well, "hello" is fine, but it's not really _exactly_ what I want.
Can you guess where I'm going next?
Let's make it "hello world".
So let's rename "hello" to "hello world".
When we click on *Rename*, we can see the Pipeline as "hello world".
But if you look up in the URL, I also see a space here.
That's not really what I want.
In fact, if I click into it again, that could be really hard to work with from CLIs or using `curl` or `wget`.
So for my URL, I really want to put in a hyphen.
So let's go ahead and rename our job one more time here.
Let's change this to dash.
I click on rename and now my Pipeline is named "hello-world".
If I look up in my URL, it's also a `hello-world`.
That's exactly what I wanted, but really, it's still not what I want.
Now at "hello-world", I'm okay with here, but looking at my dashboard, I see `hello-world`.
Well, really what I want to show, especially when I'm on the dashboard view in this case, is I want to give this a more human-friendly name.
Instead of a URL friendly name, I want to have a human friendly name.
Let's go into our job and click on *Configure* and let's scroll down to *Advanced*.
Now depending on which job that you're using, this next field, which is called *Display Name*, may show up in different places.
Sometimes it will be exposed, sometimes it will be under *Advanced*.
So in this case, what I want to have is I want to say, "Hello World from the universe."
Let's click on *Save*.
We can see here that our Pipeline name now is "Hello World from the universe", but our project name or our job name is still "hello-world".
So if we take a look up in the URL, it's still `hello-world`, but in the breadcrumb, we see the full display name that we just typed in.
In fact, when we go back to the root of our dashboard, we can see "Hello World from the universe".
If you have any questions or comments, you can reach out to us on Twitter @CloudBeast.
If this video was helpful to you, give us a thumbs up.
And if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button, and then ring that bell, and you'll be notified anytime there's new content available on CloudBeesTV.
Thanks for watching, and we will see you in the next video.

====

== Moving projects

Move an existing project to another folder by clicking the "Move" action on the project page.
When a job is moved, other jobs that refer to the job by name must be updated to match the new name.

.Move a project
video::Mof_YRGZLd8[youtube,width=800,height=420]

.Click to reveal the transcript
[%collapsible]
====
Move a Jenkins job to a folder. (upbeat music) Here's today's starting point. I have a Jenkins LTS controller, version 2.346.3. And on this controller, I have a sample job. First off, let's take a look at the options for this job. If we click on Test Pipeline and look at the drop-down that shows here, notice we see changes, build-now-configured, delete pipeline, full stage view, rename, and pipeline syntax. What we don't see is the ability to move. In order to move a job around on a Jenkins controller, we need to first have a folder. So let's go into new item. Let's create a folder. We're going to name it alpha. I'm not going to make any changes to this. We'll just click on save. Let's go back up to the root of our controller. And now when we click on this drop down beside test pipeline, we now have a move option. So let's go ahead and select move. And then it asks us where do you want to move this pipeline test pipeline to. Now if I left it at Jenkins, that would move it to the root of Jenkins while we're already there. What we want to do is move it to Jenkins Alpha. So we can select the drop down and click on Move. Now watch our breadcrumb. Right now it's dashboard and test pipeline. Click on Move and now you'll notice that test pipeline is under Alpha. Let's go ahead and click on Dashboard. You'll notice that test pipeline is gone from the root of the controller and when we click into Alpha, we now see test pipeline in the Alpha folder. If you have any questions or comments you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up and if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button and then ring that bell and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching and we will see you in the next video.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Move a Jenkins job to a folder. (upbeat music) Here's today's starting point. I have a Jenkins LTS controller, version 2.346.3. And on this controller, I have a sample job. First off, let's take a look at the options for this job. If we click on Test Pipeline and look at the drop-down that shows here, notice we see changes, build-now-configured, delete pipeline, full stage view, rename, and pipeline syntax. What we don't see is the ability to move. In order to move a job around on a Jenkins controller, we need to first have a folder. So let's go into new item. Let's create a folder. We're going to name it alpha. I'm not going to make any changes to this. We'll just click on save. Let's go back up to the root of our controller. And now when we click on this drop down beside test pipeline, we now have a move option. So let's go ahead and select move. And then it asks us where do you want to move this pipeline test pipeline to. Now if I left it at Jenkins, that would move it to the root of Jenkins while we're already there. What we want to do is move it to Jenkins Alpha. So we can select the drop down and click on Move. Now watch our breadcrumb. Right now it's dashboard and test pipeline. Click on Move and now you'll notice that test pipeline is under Alpha. Let's go ahead and click on Dashboard. You'll notice that test pipeline is gone from the root of the controller and when we click into Alpha, we now see test pipeline in the Alpha folder. If you have any questions or comments you can reach out to us on Twitter at CloudBees. If this video was helpful to you, give us a thumbs up and if you haven't subscribed to CloudBeesTV yet, why not? Take a moment, click on that subscribe button and then ring that bell and you'll be notified anytime there's new content available on CloudBeesTV. Thanks for watching and we will see you in the next video.
Move a Jenkins job to a folder.
Here's today's starting point; I have a Jenkins LTS controller, version 2.346.3., and on this controller I have a sample job.
First off, let's take a look at the options for this job.
If we click on *Test Pipeline* and look at the dropdown that shows here, notice we see *Changes*, *Build Now*, *Configure*, *Delete Pipeline*, *Full Stage View*, *Rename*, and *Pipeline Syntax*.
What we don't see is the ability to move.
In order to move a job around on a Jenkins controller, we need to first have a folder.
So let's go into *New Item*.
Let's create a folder.
We're going to name it "alpha".
I'm not going to make any changes to this, we'll just click on *Save*.
Let's go back up to the root of our controller.
Now, when we click on this dropdown beside "test-pipeline", we now have a move option.
So let's go ahead and select *Move*.
Then it asks us "Where do you want to move the Pipeline 'test-pipeline' to?".
Now, if I left it at Jenkins, that would move it to the root of Jenkins while we're already there.
What we want to do is move it to `Jenkins >> alpha`.
So we can select the dropdown and click on *Move*.
Now watch our breadcrumb -- right now it's Dashboard > test-pipeline.
Click on *Move* and now you'll notice that "test-pipeline" is under alpha.
Let's go ahead and click on Dashboard.
You'll notice that "test-pipeline" is gone from the root of the controller and when we click into "alpha", we now see test-pipeline in the alpha folder.
If you have any questions or comments you can reach out to us on Twitter @CloudBees.
If this video was helpful to you, give us a thumbs up and if you haven't subscribed to CloudBeesTV yet, why not?
Take a moment, click on that subscribe button and then ring that bell and you'll be notified anytime there's new content available on CloudBeesTV.
Thanks for watching and we will see you in the next video.

====