Jenkins Online Meetup, 15 Feb 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: User Friendly Ways to Create Pipelines

Description

This meetup is devoted to Pipeline development and will be beneficial to Jenkins users of all levels.

We'll have speakers talking about the new Declarative Pipeline syntax, building basic and advanced Pipelines, and finally a sneak-peek at the new Pipeline Visual Editor from Blue Ocean

A

Patrick, you can begin.

A

A

Patrick of your speaking, we can't hear you.

B

I got lead somehow sorry about that.

B

Apologies for a little bit of coffee, er um so again welcome to today's online Jam thanks for joining us today, we're going to talk about declarative pipeline and some of the new things that are coming in the blue ocean in the future as well. For that so to begin a little background on that about a year and a half ago, Jenkins passed a hundred thousand installations for the number they're being reported back to the stats for Jenkins.

B

Today, we're around 160,000 installations of Jenkins of that we've got almost a hundred thousand Jenkins 2.0 or 2-point X installations out there around 600,000 agents and around two million users across multiple millions of jobs out there and, according to the latest survey, 90% of the people using Jenkins, have seen their use of Jenkins in their businesses grow. So we're seeing more and more uptake of Jenkins across the organization's last year under a year ago, I think in April last year right around March April timeframe.

B

We released Jenkins 2.0 with that the three major pillars that we wanted to look at, that we're pipelines, usability and getting more users for scale on Jenkins. So this today is a little bit about mostly pipeline, but also around usability from specifically around pipelines. For that so again, we're gonna be talking about pipeline. Mostly today,.

B

Hopefully, by now almost everybody who's been exposed to Jenkins has heard of pipeline is code is something we came up with with the pipeline plug-in and Jenkins as a new way to do, builds and also to extend that to continuous delivery in your organization, and with that we created, what's called a Jenkins file, you can store in your repository so that you can actually have your continuous delivery pipeline, be auditable, make it more portable, move it from Jenkins to Jenkins.

B

It's also durable, because pipeline will restart from a crash if the master goes down or you need to restart the master for maintenance reasons, which is another big reason why pipeline was redesigned for that. It's extensible, we have the shared library, so you can actually add more features to that. It's also extensible via plugins, and one of the goals with that was to make your pipelines be more dry.

B

So you didn't have to recreate the wheel every time you did, that and by automatic I mean that when you go into a new environment with an organization folder or a multi branch, when you add the jenkins file to your repository, it automatically creates that job within your jenkins and start running it, which is a big thing.

B

So you don't need to go in and configure a job every time you want to do that in Jenkins, it's much more automatic and everything's automated for that, and it also means automated pull request building within those organizations folders as well.

B

So with that, because we had pipeline and pipeline originally was a groovy DSL, it's still a groovy DSL, but that meant you need to have some knowledge of groovy to be able to actually create your pipelines in there.

B

We wanted to actually extend that to more users to make the barrier to entry for making those jenkins files a lot lower and with that, looking at the number of users across that there's quite a few users in the intermediate and beginner range that aren't necessarily going to be the people who pick up pipeline and learn groovy to do this, and we wanted to be able to extend that back so that everyone from beginners to intermediate experts can actually use pipeline and take advantage of the jenkins file across their organization.

B

So some of the goals we had with declarative pipeline the first was to separate all the concerns and by that with Jenkins there's the Jenkins. You need to be able to understand how the build agents are set up. Sorry, the agents are set up and set up your everything else around your pipeline and then construct your pipeline within that. So we learn to actually separate the structure of the pipeline from what the pipeline was actually doing.

B

So you could actually create more consistent pipelines across that without having to understand all the Jenkins internals behind the scenes. The next big goal was to actually have a lip a so you could actually create pipelines consistently in a very best practice manner, as opposed to having every pipeline be a snowflake. It's not going to be coated. You don't have to worry about coding.

B

Styles, you have one set of ways to create a pipeline, and then the difference is and what the steps are within the various stages and also what the stages are for that one of the other big advantages of this is that it's more predictable, I can look at a pipeline. That's been written and declarative syntax and understand what it's going to do much faster than if it's written in an imperative programming language where I have to go through and figure out what all the programming steps are going to do to create that pipeline.

B

So it makes it much easier to quickly look at a pipeline know exactly what it's going to do and go from there. This also allows us, as you'll, see later, to have the GUI on top of that to construct that pipeline, because it is a predictable model, that's being used for declarative.

B

Lastly, the the big goal was to be able to pull in all major stakeholders in a continuous delivery pipeline that could actually look at the pipeline. Do code reviews because it's easy to acock and easy to understand, so more people can be involved in the process, contribute to that and write those pipelines, or at least do reviews on those pipelines without having to understand the intricate details of all the groovy, that's possible within the scripted pipeline.

B

For that one other note before I hand this off to Andrew and I'm sorry I'm running through this quickly, just because I'm sick is that we've updated all the documentation on Jenkins I/o. If you go to Jenkins I/o Docs Tyler's done a great job of updating all those documents and Liam's contributed a lot and more and more blogs going to be released over the next couple weeks for a lot of these things for a declarative as well. So there's been a lot of push on getting information out about this.

B

This new way to create pipelines for that. So with that I like to turn over to Andrew, and he can start showing the the syntax in in action and the structure that syntax.

C

Okay, first thing everywhere now: Patrick a commute. Thank you so I'm going to do walkthrough of some of the syntax for declarative pipelines. Bobby Sandow will be talking some more about some other parts of the syntax. But let's do a quick walkthrough here. This is publicly visible.

C

There's the URL in case you care, look repo, but we'll go through this and just take a look at what's involved in the syntax. So first of all, this is the most important part is that everything in a declarative pipeline is nested within a pipeline block in your Jenkins file. Anything outside of the pipeline block doesn't count as declarative is not parsed as declarative will mount roundtrip with the editor and more so yeah. If you want to use it declared a pipeline, you got to use that pipeline block the first directive.

C

We're going to look at here is agent, which defines where the pipeline will run. The example I've got here is a pretty simple one. This is label nothing which means it can run on any label. I also could have just done agent any that has the same meaning, but I wanted to show that agent normally is a block, not just a simple expression like agent any or agent, none which are two special cases.

C

There's other possible built-in agent types as I mentioned, there's agent, none which you can use at the top level of the declarative pipeline to make sure that you're not running on any agent.

C

But in that case you will need to specify your agents in each stage explicitly so generally you're not going to want to use that and there's also a docker agent type, which Bobby will go into and docker file, which we will not be touching on much stay but which is up on the documentation in how that the next directive that I'm going to look at here is the tools directive.

C

The tools directive works with the tools that Jenkins is able to do. Auto installation such as maven, JDK and plenty of other plugins provide additional tools such as Gradle NPM and a lot more, and it is important to note that tool. Installation doesn't work quite right with dr. containers currently. So this is useful when you're running on a label, but not as much when you're running with docker docker file, so be aware of that.

C

The syntax for declaring your tools is pairs of tools, symbols and the installation name. That's configured in your Jenkins masters tool configuration not all tools actually have those simple string, symbols and if they don't, they won't work in the tools section declarative. So when you run into a case like that, when you get an error because foo tool does not show up right, open a ticket against that tool, get them to add that symbol and then they'll be fine.

C

But here we're gonna see when I actually run the build that there's going to be a validation issue, because there isn't actually, on the master. I'm gonna be running this on a maven tool. Configured named maven, three three eight! So we'll touch on that again when I actually go to run this at the environment section strangely enough sets environment variables. That's another thing that Bobby will look at in a little more detail with the credentials function that you can use inside the environment, block environment.

C

Variable identifiers need to be both valid bashatt variable identifier, since they end up in the environment and valid groovy variable identifiers, x' or the syntax fails.

C

If you don't use a valid identifier, you will get an error at validation time, while I don't have an example of that. Failing here, I will show you what those validation failures in general look like.

C

You can't do more complicated, groovy expressions or nesting of environment variables like foo equals bar bar equals dollar foo currently, but that should be possible and not too long once a pending pull request gets merged and released so that we are moving forward and making sure that we're fixing the gaps, but not everything necessarily works perfectly right now.

C

The stages section contains a list of stages. Strangely enough, and at least one stage is required, here's what a stage definition looks like to start and every stage block must contain at least one le a one steps block with at least one step.

C

There are additional sections, a couple of which look at below, but the only one that's required within a stage is the steps block and a steps block contains a set of steps, as you would use in declare an scripted pipeline as well. There are some exceptions here that you will find errors about. If you try to use, we don't allow variable declaration, you know foo equals bar. We don't allow if statements or loops or method calls on objects, you can use all of that stuff.

C

But if so, you have to do it within a script block which I don't have as an example here, but you can use steps that take another block of steps as one of their arguments, though, like here where I've got a timeout step except again, we've got another couple: validation issues, I didn't use the right type for the value for time and I have a typo in unit again we'll look at that in a little bit and you'll see the error that that produces, and then it will fix it.

C

So the steps here are pretty minimalistic, we're just running some echos because we're running in that timeout. Theoretically, it shouldn't take longer than well true minutes, but that's obviously wrong. It should be five and here we're showing that the may be an installation that we did above again once we fix the validation will create the version number that we're expecting so it's Auto installed. Maven made sure it's on the path made sure the JDK is set as well, so that we can actually run maven.

C

The Post directive can be used both on an individual stage isn't doing here or for the entire build here, I'm just doing some simple success and failure. So if the build succeeds, we echo one string. If the build fails, we echo a different string, there's also unstable, always and changed always well always run will actually have an example of that later.

C

Success, failure and unstable will run if that status is, and if the build currently has that status and change will run if the builds status at this point is different than the previous build status. So now we get to our second stage, and we see that we can do things like override tools, environment and agent on a per stage basis, so here we're overriding the original maven tool with a different version. So now maven version should give us a different you than it would have before. Now.

C

Here's a third and final stage showing how to use parallel in declarative parallel can be used, but if so it could be, it has to be the only step that you invoke in the steps block. You can't combine parallel and other steps to enable a good validation model on the back end.

C

There is some syntactic sugar coming to make this easier so that you can have whole stages executed in parallel, but that has not arrived yet so for now, these parallel blocks will all run on the same agent that the rest of the build is running on or that the particular stage is running on, but it's the same, parallel syntax as in scripted, it's again, I'm not doing anything particularly meaningful here, but and now here's our post, build post.

C

So, as I mentioned always always runs it's the first one that runs it runs before any of the other post conditions are evaluated.

C

So no matter what at the end of the build, even if the build is failed, will delete the directory and wipe the workspace and again the simple success in a simple failure here, using the mail step just to let us know that a build has passed or failed, and one of the more.

C

Advanced options, I guess, would be the options directive. This contains configuration that applies across the whole job. For example, we've got the build discard or setup here to make sure that we're only keeping 10 builds at a time so that we don't fill up our storage and since we'd like to make sure this bill doesn't take an hour. Let's set up a timeout that applies across the entire build, rather than just a few steps.

C

So let's are there any questions? Yet? Okay, then, let's, let's see, if this runs, let's go to blue ocean here, I've already run a couple runs first, one failed second one pass, but now this one should fail: let's see what happens yep. It failed because I added validation errors. Let's take a look at what those errors look like. So it's before it's gotten any further in the build than just checking it out and parsing the Jenkins file. It's looking for errors and telling me what those errors are. So here.

C

It's telling me that at a particular line that I've got a the wrong type parameter type for the time parameter for time out and that I've got an invalid parameter name along with a suggestion for what the correct one is, and then we get the additional validation here about the tool where it says: wait, there's no three!

C

Three eight did you mean three, three nine, so we've got that nice validation that runs before you're actually executing the build so that you don't have to wait an hour and a half to find out that you've got a typo in parameter, name or the wrong parameter type, or something like that there. You can also do this with the Jenkins CLI and the editor. Does this validation more or less in real time?

C

So let's go fix those errors where do I have that ah there we go all right, so, let's edit here so that first error hold on was because we had a bad maven version here. So let's change that to three three three, which is what we meant to do so that validation error goes away.

C

Our next validation issue yeah. Let's do that for five minutes with a unit and that should actually work now, let's scroll down, it's those pets, the validation issues commit the changes and let's run it again and see what happens.

D

C

Taking a little while, it's probably installing things- let's see what's going on here, so we can see here, that's executing it's in the first stage. Currently it has completed so you can see that the Nifty and pretty blue ocean visualization, if you haven't seen it already now, if we look at the output from that first stage, we can see what maven versions it said. haha It said: 3 3 3 as we wanted it to it, automatically installed it. It also complained a little, but that's krump another. We had to worry about now.

C

In the second stage we were overriding, the maven version. Let's see what version it gives us here, aha see it did correctly override that maple version and give us 339, and then we've got our three parallel stages: Oh three parallel blocks, rather each of which are printing who they are where they are and that's pretty much it so.

C

Any questions that I should answer before I go back on mute.

A

No questions Andrew great. Thank you very much.

E

Ok, so for those are wondering where to ask questions, it's in the Jenkins channel on freenode, just an FYI, so I'm going to show some bits of how to do a bit more advanced stuff, even though the declarative is not really meant for super advanced things. But we can still do some cool stuff in here.

E

So my example is also on my github account the spring pet clinic that I've worked and written a Jenkins file for that.

E

So starting off, we I am getting an agent on the docker label and I started off. My stage is quite directly start with a build stage, and here I don't want to use tool installers, because dr. is much cooler, I think so.

E

I am saying I say here that I would like to run inside the maven 3:39 docker image and I want to reuse the node that that the pipeline is currently running on so I get an agent up here that I'm running on and I'm then sort of starting up a docker image there to run this stage and in my silly example, and most developers thinks that unit tests are running too slow. So they only want to run fine bugs here.

E

So we run fine bugs we skip the tests and then in the post section. If we are successful, will collect those fine box reports, then we move on to the test stage again starting up a new docker image with the same image name, we reuse the same agent, meaning that we are also keeping the workspace.

E

So don't have to do a check out again. Basically- and here is the condition under hinted to earlier I- think so we will only run this stage if the branch matches this pattern. So if we are on the master branch, this stage will run and.

E

Simply as an example, here we run the package with the integration profile set, don't look in the palm file because there is not no integration profile set, but as an example, and we could run the integration test here and then we will always here since archive artifacts. We can tell that step to not fail the build if there are no other factor.

E

Even if the bill failed up up there, we can sort of always make sure to try and archive the artifacts and then, if, if we're, successful or unstable, because fine box could have marked this as unstable, for example, I will collect the unit test reports and moving on to the next stage.

E

We do a release test and we, but we will only use, do the release test stage if the branch matches release something and just for for giggles running the maven command, and here I'm, using some groovy g-string magic to take the branch name and drop everything that comes after the last and then adding the build number, meaning that if the release branch is released, 1.0 the version I'm sending in here would basically be one dot, o dot. Whatever build number we are running currently so just to show the difference.

E

Everything in in within these brackets is interpreted by groovy, and this is just sent out to the shell command, as is meaning that bash will actually do this part just so that you can understand the difference there and I'm saying here, always okay, their artifacts, since, if we are in the release branch, this test stage won't run because the branch name is not cold master. So we'll archive the artifact here same thing again with allow the empty archive, so we can safely run this post stage always and success or unstable.

E

We run j-unit and here also running the release profile.

E

And then the last stage will actually perform the race, and here is a different way of. There are a couple of different when conditions you can use. You can use branch, there is an environment and then there is also an expression so and inside the brackets. Here you can use any groovy expression. Basically, and the sad part about using the expression is that the there won't be any of that nice validation for you that andrew showed before so.

E

This will just be passed on to normal scripted pack behind ass as usual, and if, if you look at my commit history, you might see that I've had some issues with my groovy stuff I needed to do different, commits to fix that.

E

But here isn't just another way of just looking at the branch name, so I'm checking if the branch name it contains release and if the current result is null, meaning that the J unit tests before fail, because when we are collecting the J unit test of if there are any test failures, the build will be marked unstable, meaning that this stage will be skipped well because it will only run if we don't have a result yet and then for the environments.

E

I am grabbing the credentials with the ID SSH Bob and I'm, adding those to the release or the realm prefix so available to my steps or in the environment. For my steps there will be a rel USR and a rel PSW, as well as a rel that contains the user, colum password and then I run my perform here.

E

The perform release with the username and the password that is available as environment variables and then sending away an email, but my local machine doesn't can't relay email so just to make sure that it works on echoing this out here.

E

Any particular questions so far is easy. So we looked here in blue ocean. You can see that I have a couple of different branches. So on the master branch you can see the latest build here since, before a master, we ran the build and the test stages will run, but we skip through these tests and release, push.

E

And I always keep forgetting that that's a dialog while on the my dev branch, for example- it's not called master, so we are actually only running the build stage.

E

And on, for example, released 1.5 we ran build, we skip tests because we're not on the master branch release, test and release push were executed.

D

And let's see if I can find.

E

Yeah, if we look at release push, we can actually see that the version is, can I see the build number do ya there. So this is build number 14. You know what who actually released was one five fourteen.

E

Okay, so that's quick and easy.

E

Thank you, I think I'm done. Man.

F

All right, Thank, You, Bobby, okay, so I am going to talk to you about the blue ocean pipeline editor, and this is currently in preview and we'll go over some of the various things that it does have a demo and they look at what is planned for the future.

F

F

Just why do we need a visual editor? You know I think. If we go back to, why do people use Jenkins? We can answer this question fairly. Simply there are lots of reasons to use Jenkins. It does great things, but a lot of developers use Jenkins because you don't really have to write any code to get rolling.

F

You know you can go and configure some kind of a job just using configuration, forms and, and that's very appealing to a lot of people because you're already busy writing code for your own application, and then you know using the free style. The experience is very easy. You just use a plug-in. You pick some some of the different things that you need. You fill out the fields, so the visual editor is really a way to bring that ease of use of of the freestyle builds.

F

You know into a context that everybody can start getting the benefits of a pipeline, and you know one of the other things that it does is puts things in one place. So you know, I can remember countless times, chaining together, countless downstream jobs and configuring a bunch of different things, just because I needed to with Cranberries triggers and all those things, but by being able to put this into the pipeline form you're able to leverage all the stuff that you can do there in sort of a centralized place.

F

So you know again why a visual editor well pipeline is is great and especially the declarative. It's it's really kind of made it a lot easier and more approachable to make pipelines, but it still does have a moderate barrier transferee. You know you need to know what steps to type you need to know what parameters.

B

F

Have you need to know what the data types are as Andrew showed you? You know you get validation errors at one time and and it we and I said some of these things up front, and you know it's just another thing, as I said for developers to learn.

F

When you know a lot of people are just busy doing other things, and the other thing, of course, is just it's not easy to visualize the text file, sometimes especially if it's a fairly large one, that's spread out a bunch across a bunch of different parallel nodes, and things like that so having the pipeline editor certainly is one of those things that that helps to kind of you know, get the story right in the in the beginning, so who is it for probably not targeted as targeted it as advanced users, and it only supports declarative pipelines?

F

So you know one of the questions. Actually, that just came up in chat was you know about doing some dynamic, different stuff that you know declared it didn't actually support. So you know those types of users are still going to probably have to go use the standard scripted pipeline, but really anyone who wants the easiest way to get started with pipeline. The editor is, you know something that's available to you, know kind of what's there and give you a guided forms and, and that sort of thing to you know, to build the pipeline out.

F

And so just a brief history about this.when pipeline was was kind of a a year ago. There are a few of us that, were it really pumped about it and wanted to make it more accessible for for everyone, because we can see all the benefits that that people got from it, but you know so. This is not the first time there were some pipeline editors created, although the other ones were some quick prototypes, so it all sort of started with Michael Neil spearheading this.

F

You know with something like hey: we should be able to make something that generates pipelines pretty easily, and so he he whipped up a JavaScript app. You know and know in short order, and- and we could see hey this- this might work.

F

Okay, and you know then I actually took this a little over a year ago and whipped up a different one, and in this one we decided to go with react, and so we made some safaris into that and actually ended up being such a good experience that it sort of paved the way for for blue ocean to to go that way as well. But the thing that we really ran into was the fact that that we didn't have any two-way conversion.

F

So you know this editor basically was using some kind of a separate file which was really not gonna work for things like multi branch.

F

So you know just a quick recap here: a pipeline in blue ocean, you know, blue ocean is, is built for pipeline and that's you know that the focus pretty much from the get-go and it has excellent music visualization of pipelines. You know one of the things as it shows parallelism.

F

You know in way this stage view doesn't show and a lot of the other things didn't really show and that's just kind of fundamental to what we wanted to do to you know to really show people what their builds were doing, but then to take that a step further. You know we wanted to make sure that it was consistent between running and editing so that you know if you go and you make a pipeline that has some parallel stages.

F

You you know you should expect, is pretty much see the same thing when you go and execute it as well. So.

F

You know the pipeline. Editor basically, is. Is that that you know it's there? It's it's here to lower the barrier of entry to use pipeline. You know just again to to fill the void where freestyle builds were really easy because you could click your way. You know to to having something run and then also to provide a visual representation of how your pipeline is going to be executed, serially and parallel. You know across the have you've configured it as well as doing things like showing errors as soon as possible.

F

So you know again referencing Andrews example. You know, while it's awesome that that we get errors and- and that's like the validation is amazing, it would be really nice to know that we had them right away before we've been running the pipeline, so you know a lot of things are, are validated upfront and- and you can see him editor exactly where there's occur. Another thing is that similar to blue ocean editor is kind of design driven.

F

So it's you know, it's being thought about and taken down a path where you know we got got design work going up the front to make sure that you know this is something that is going to be really usable and approachable for in everyone and one other small bit is that the pipeline editor in the in the preview? It does a thing where it just saves your work, so you swap over here to do my own and.

F

Okay, so what we're looking at here is is the pipeline editor. This is just a very basic pipeline that doesn't really do much of anything. It just has a single stage called build, but you can see quite clearly it starts you know somewhere it goes to the build and it's got a couple of you know things you can add serial steps or you can add parallel steps. The other thing is when you're looking at this, this main view here over on the right.

F

This is basically where the editing happens, and so you are presented at first with the general pipeline settings. So, for example, where is the build gonna run? So you could pick you know the docker any of the particular plugins that are there, but you could pick docker and let's say we want to run HTTP d2 to 12 or something like that. You can give it some some args and that's you know just a very quick and easy way to set up a an agent can set up environment variables just by adding new ones in here.

F

So, for example, you could is there and if you want that to be either a patchy and but uh home folders or whatever, and put that somewhere.

F

Like that, and so that's sort of just the very basic top-level editing that the editor provides and and it's going to have some more things, there I'll talk about that a bit later and then to edit a particular stage. You just click on the stage and you get the particular you know editor over here. If you want to change the name.

F

Just type right there, if you want to delete the stage, you can just click these little dots here and do the delete and then it shows you a list of all the particular steps that are there, and you can see this. One just has a print message with a whole other world and so clicking on that would bring you bring up the editor for that particular step. I mean you see that that's really all has their and we can go ahead and add some different steps. So maybe maybe we'll just rename this to.

F

And it'll add a step and want to you know, call some maven commands and greens tests, because we just want this to be a good build and we get. You know something all the steps kind of listed out there. The other thing we can do is support a nested steps. So some of the things you see, for example, allocating a node you might want to allocate I know the windows label right here, and you can see that then you're able to add child steps to you know to this particular node.

F

Much like the you know, just the declarative has the steps nested and and in a very obvious way, this works recently. Similarly, so let's go ahead and add a step in here, and this could just be.

F

F

Okay and then, if we go back out to the to the top-level stage here clicking on the to build quick, you actually can see all of the steps, including all of the nested steps here very quickly, so it makes it easy to see exactly what's going on for that particular stage now we can go ahead and add a serial stage by clicking the you know the end here. It basically brings you to something you can start typing with. So let's say this: one is test and I'm gonna say: that's.

F

That's just fine for now, but you'll see that the editor actually shows now that there's an error, it's gone ahead and it's continuously. You know at appropriate times validating this. This pipeline against, so the declarative, validator and so will see here that something happened, and so I can just click here and I see Oh at least one step is required right. So so let me go ahead and just just fix that for now- and this might be- you know.

F

Okay and I said what I did that second here, but so now I've got you know, I've got a particular test and it's for the Chrome browser and my hair is one away. Everything seems seems, don't fine here now. If I want to add parallel steps, I can just click the appropriate. You know icon aligned with at one of the other stages. So let's say I want to add Firefox tests and I'm gonna hide and just and a script as I know it needs one.

F

F

One other thing here: just a label on that. So now we have a you know we can see if you've got a quick, build and we've got a couple of tests running on Chrome and on Firefox here, and this is gonna. Gonna correspond exactly to what gets displayed in you know in the and when it when it runs.

F

That's sort of you know that the the gist of of how this works, a couple of notes here, you'll see that I've got a nice custom editor for a shell script and the other steps. If I go in here and add some other sort of step, I've got a print message. Let's say it gives me some sort of a editor here. These are actually dynamically generated. So it's not really much work at all.

F

When we add new steps in- and we can just sort of sort of use, use the step metadata to be able to figure out a quick editor to show everybody with the option to make everything a lot nicer, we probably will we'll tweak some of the things you know the more more things in the future.

F

Now the other thing about this preview, the way the preview works is you basically just have a new and a load save button, and so the load Save button takes what your current pipeline is and converts it into the declarative script. So when you click it, you just get a text box. That's been converted into the declarative script, you see, I have a docker image. You know it shoots me 2.12.

F

It also lets you just go ahead and paste a declarative pipeline right in there. So if I go ahead and just copy one from elsewhere, again paste that in here and click update and and you'll see it's it's updated that, with with a declarative pipeline that I just used, so that's more or less how that works. The new actually just provides kind of a very basic pipeline with a few. You know single parallel step, and you know a couple of serial steps right there.

F

So that's more or less the state of the editor here. So let me switch back over to.

F

F

Alright, so, like I said that right now, there's basically a basic pipeline functionality step editors are dynamically created, based on on what the metadata, the steps are, looking for, sort of the same way that they're being validated by the declarative and most of the things just work. There are a few data types that some of the steps require that are not supported. So you'll see a message and editor about that and, as I said, there's the ability to make custom editors where it makes sense.

F

So you know having a big script editor or something else, and probably a few of those will want to go and tweak in the future and just a quick example of that this came up I. Think last week, somebody you know, sent a message on the on the chat or something about you know. There's this with maintenance step. What do we need to do to get this working and declarative, and and what do we need to get to get it working in the editor and so I?

F

Just we loaded it up and it looks like you know: it's everything's, just fine and it it. You know gives you all the the properties and whatnot you know again. This is one that might be nice to clean up, but but the fact that it just works out of the boxes is pretty useful.

F

So what's next for the for the editor and and of course you know, this is all subject to change this is you know some of the things we do that's discussed as plans and and that sort of thing, so you know up next we're looking at basically ground tripping with multi branch projects, adding a run replay us and, of course, supporting more declarative features, adding in a beginners tour, because you know again what we really want.

F

The editor to be is a way for anybody at all to be able to get started with pipeline, whether you're, a beginner or an intermediate user or an advanced user, and just prefer to do things that way. So that's that's what we're you know really looking to do and and of course right now, the the preview doesn't support rearranging things and we'll get that fixed up, of course.

F

So round-tripping you know basically to describe what that is. We're looking at taking existing pipeline jobs and being able to edit them or you know if you've got us an SCM somewhere, you know get repository being able to take a repository that doesn't have a pipeline job in it at all. I'll go through the editor and create one and save that back. So we want to be able to you know to make it very easy for anybody.

F

Who's got a git project, let's say or github project, especially to to be able to save things back to the SCM.

F

Now, just to give a little context about how you know how the preview is versus how things ultimately are going to be right now, like I said, the preview has this kind of load save feature where you can get the pipeline and you sort of can copy and paste, because some of the other things were still waiting on being fleshed out all the way, especially with you know, saving back to the SEMS. But ultimately you know there's.

F

This is tied. You know directly with with what we call the creation flow, and so what happens you know in an ideal world? Is somebody you know comes in and and goes and selects you know, I use get to store my to store my coat in and they go and and choose that and and then it detects if there's a Jenkins file or not, and they might want to create one. And so then you know, what's going to happen is the flow is going to change? You know how how the preview works to to be.

F

You know tightly coupled with the creation and then also just with you know, editing and looking at branches, and things like that where you want to go and and change things, but it really ties together.

F

You know the usage of if the editor with with you projects, so you know just a really quick screenshot here is that you know the editor. Basically, it's it's it's. The creation is being worked on, so you, like I, said you kind of select red code is and optionally go and ultimately create or edit it and, and you have the option to use the editor there.

F

Another thing that that is, is you know, high on the list of things we'd like to see is getting the run and replay done so you know this is something that already exists for for Jenkins files. You know you can go and run and run and go to the the run history and then you can go and click the replay button and you get an edit.

F

You know a text editor at least for for Jenkins files, but you know we'd want to bring that to the editor and and so again for people who who want to be using it. It makes a lot of sense to be able to just you know, click a button essentially and say: okay, go ahead and and try this one out, because when you're developing these you know these Jenkins files, you want to be able to do a quick iterations during development.

F

You know, upcoming sale are more features, we're looking at doing a better experience, selecting things so, for example, docker images right now, there's you know, text box that you can. You can just go type something in and and it's pretty easy to know what you need, especially you can go search to dr. registry or maybe you've got a low, but you know but we'd like to make that maybe even nicer and try to see.

F

Oh, do you have a you know a docker registry configured somewhere that we should be looking at and give you some some. You know completion on it or something like that.

F

Also, when you're editing steps we'd like to make environment variables available, so you know they lease the things that that we can determine based on on Jenkins, just as you know stuff to make it easier again to do the right thing, the first time and we're gonna make you know, input steps, probably a bit better and credentials kind of to first-class citizens and ways that makes sense as well, I think and then, of course, we're gonna, add a beginner's tour.

F

So you know the things that you've probably seen it countless other websites just something that walks through what are all the features are and walks through somebody creating a simple pipeline. It's so that they can get an idea exactly what they should be doing and then a little more detail about what's coming up next, these are probably the the shorter term things that we're looking at getting done and, and most of this is going to be to align with with the declarative itself. So you know, post steps, give this a no brainer there.

F

There you know necessary, and so we're probably going to have something. You know a bit like what the step editor is today, and you know this is something that were we're still working on the design for exactly what you know, how we want to present that and how that's gonna going to work best and be easiest to use, of course, we're going to have some tool configuration.

F

This is one of those things that actually is. Is you know pretty helpful for users, because you know going back to Andrews example: there wasn't a maven, you know three three three tool available, and so you know it's tools are basically just whatever you have configured in your Jenkins instance and we've. You know we can give somebody an easy selector to say: hey, I'm gonna, you know be able to use these tools and select what what we can do and and just again try to avoid errors. Upfront, we're gonna, add in per stage configuration now.

F

There's one one caveat here, which is the stages are currently all top level. So basically, what you're looking at is, in addition to you know the the global configuration where you can select agent and environment things like that, just like Andrew showed you'll be able to in the editor, select the top level stage and configure an agent, their environment there and the other sort of things that make sense. You know post-post steps as well that sort of thing and we're going to you know, look to have more alignment with declarative.

F

You know again, so configuring run retention having parameters having you know a nice editor for parameters. This is one of the things that that sometimes is, is a bit tricky.

F

So you know again try to try to do things one step at a time and and do them the right way that you know it's gonna make make this a pleasure for everybody to use who wants to you know adding support for the when stage or the wind condition within stages is is obviously another thing we need to do as well and, of course, doing drag and drops between between steps and stages, or you know, maybe something else just because you know those things sometimes tend to be a little a little, odd and web.

F

You eyes or just you eyes in general, so you know whatever whatever we decide is gonna make the most sense we'll try to do our best to get that get that working, and so that's more or less all I have today. But if you'd like more info the preview of the editor that I showed you is currently available in the update center. It's the the blue ocean pipeline editor, so you can install that make sure you have blue ocean b23 installed.

F

If you do because it's it's it's sort of tightly coupled with the various pieces there and github URL right there, you can take a look if you're interested as well. All right so, like I, said that's pretty much, but any questions hey.

A

Keith, can you help explain what round-tripping means.

F

Sure, yes, so maybe I should should get back here. It's truth, being okay,.

B

F

Tripping, like I said, is basically editing existing pipeline jobs or you know creating from scratch, so in a an ideal world. What what we would like to see for the experience to be for you know for for everybody who would like this? At least you know new users, especially people who you know, who want the easiest way to get started with pipeline.

F

Round-Tripping is kind of a key part of this, and and what that means is you know? Essentially you go through a flow. You know the creation flow and you it prompts you to. Where do you store your code right? So you might be a storing code on github, for example. So if you are, you know, you pick github and maybe go and say: I want to build one more pot.

F

You know one a git repository you'd select that repository and at that point you know basically blueish and would look and say: okay, is there a Jenkins file? Yes, I could start building it, but the thing is over time. You might need to change. You know that Jenkins file or you might not have one to begin with.

F

So, in the case you didn't have one to begin with, you could still point to a repository which right now that just gives summarily ignored by Jenkins, but you could point to that repository and say: I want to create a Jenkins file when you do that, you could use the visual editor and go and create your your Jenkins file.

F

You know basically at that point, maybe even running through some different tests and things and then, when you're, when you're happy with it, you know save it back to the to the source control system, and this is like one of the key kind of things to do, because it eliminates the need to kind of go and edit some things and then copy and paste and a different file somewhere else if you're using the visual editor, especially because it's all just sort of right there in Jenkins that the round trip really is just taking.

F

You know, taking a Jenkins file or making a new Jenkins file, putting it into the editor and then being able to save it back into the SCM. Where it's going to start. You know controlling your bills and you're going to have all of the the you know the benefits of multi-branch going on.

F

So hopefully that answers the the questionnaire Thanks.

A

So most of the questions has been answered offline, so I think we can just go ahead and close this this this online cam great.

B

Ok, well thanks. Everyone for joining today, I encourage everyone to visit. Jenkins I/o go to the documentation.

B

Section read the blogs, Tyler and Liam are doing a lot of updates there to provide more information, also send email questions to Jenkins CI users at Google, Groups comm, and you should be able to answer there or you could go live on IRC into the Jenkins channel, where most of the questions will be answered, but most of us will be available for any of those questions and we want to get everyone up and running on pipelines as much as possible.

B

These days so feel free to ask, and hopefully we'll get answers to you promptly, thanks again for joining, and please feel free to share this with anybody else in the company on the YouTube recorded version of this thanks and have a great week.