Now, let's get started with pipelines, and you're probably wondering what exactly is a pipeline anyway,
and I wanted to make a quick analogy to a car assembly line.
In order to create a car, you need to follow a couple of steps.
So, for example, you first need a chassis.
And on that, you installed the engine.
And once you have the engine, you can add the wheels and so on.
So as you can see, there are a few characteristics to a car assembly line.
There are a series of steps that need to be done in a certain order.
So you cannot start adding the wheels until you have the chassis and engine.
The steps are connected.
You can sort of say like the result from the previous step.
The output from the previous step is the input for the next step.
And some steps, of course, can be done in parallel.
For example, installing the wheels.
You can work on all four wheels at the same time without affecting the output.
Now, of course, many more steps are required in order to build the final product, not only the assembly,
the production of the car is important, but before the car can leave the factory, it needs to be tested
to make sure that a final consumer actually gets a working car so that everything works.
So the end goal is to get the product out of the factory.
Now, you'll notice that building software is, in some regards, quite similar to building a car,
and this is exactly what good lab is supporting us to get the product out of the factory, whatever
that product is.
Now, let's try to build something similar in Gittel Abassi.
From the previous example, you see that we have at least two large stages, we need to build something
and you need to test it, that it's working.
And of course, building itself has a lot of steps but will not get into that.
And testing, of course, can also have a lot of processes and steps in order to make sure everything
works, but as a big picture, they are at least two big steps involved in this process.
Now, the first step in order to get started with Gottleib is to go to get lab dot com and in case you
don't have an account yet, go ahead and create one by clicking on the register once you are registered.
Make sure you sign in.
Initially will probably not have any projects, but exactly, this is what we're going to do, Statoil,
to create our first project.
So here on the right side, click on you project.
When I called this project car assembly line.
And by default, the project will be private, and that is definitely OK.
So here below, I'm going to click on Create Project.
Not the first project has been created, and it actually is an empty its repository where we can start
adding our code or any else that's related to the project.
Now, we only want to build a pipeline.
So for that reason, in order to create a pipeline in catalepsy, we need to create a file that defines
that pipeline.
And that is quite easy.
And we'll do it using the lab interface.
So right here, you can click on your file.
And this is to have a specific name, and that name is Dot Getler, Desh Theeye, Dot Yamal.
And Yamal is a special format for files that define those pipelines in catalepsy.
So you'll probably see this format generally for specifying any configurations and such.
And in Gottleib is the only way in order to specify the pipeline, in order for Gottleib to do anything,
we need to specify a job.
And a job, as the name suggests, is a task that GitHub should do for us.
So let's say the first job is built the car.
So we're going to see here, build the car.
Column.
And then on a new line, I'm going to hit enter and then two spaces.
And then the write script.
Into more spaces Desh Now I can start writing shall commence here.
Now, what we are trying to do is to create a file and to add a few techs to identify.
So we are imagining that that file is our car and then we are going to add a chassis and we're going
to add an engine.
We're going to add wheels and put everything inside that file.
So let's create a folder.
Make directory build.
We said we're going to change the directory.
And now let's create a file.
And create a file called Card, that text, and we're going to use the common touch in order to create
a file, what touch does it changes the timestamp when a file was created or updated.
And in case it doesn't exist, it will simply create a file.
Now, what we want to do is to start adding some information to it, so let's first add to this file
a chassy.
And with this operator, we are going to replace the content of car texte with Chessie.
Let's copy this line.
And an engine.
And Wheelz.
And that's about it.
These are the steps required in order to create a car, so let's save our pipeline configuration by
committing the changes we have made to this file.
As soon as we have saved this file, Getler, BCI has detected our pipeline and you will see here,
this indicator is showing that the pipeline is running and we want to see the current progress on what
it's doing.
All we have to do is click on this image here.
Now, this is our pipeline, and as you can see, it only contains one job because we have only defined
one job.
If I click inside a job.
Good luck will execute the scripts that we have previously written and will display the output, the
tool that is writing the scripts is called the Giddyap Runner, and it very much looks like your own
terminal.
And you will see here exactly the steps that we have done.
We have created a folder build, we have created a file, and we have added this strings to the file.
And now finally it says Jump succeeded because none of our scripts had any issues.
Now, as you have previously said, we would like to add another step.
So we have this step that we just called now build the car, but we also want to test everything.
So let's go back to the project, to the killer YAML file.
And add another step.
So let's call the next job, test the car.
So always remember not to use tabs, but to use spaces when defining the YAML file, and I'm using two
spaces for indentation one too.
And now I'm adding a new script.
So the first step would be to test if the file was created, because we have created a file called Card
that texte and a way to test it would be to use the test command minus F.
And to specify the name of the file that we want to test for existence.
Now, if this command was to fail, if it was not to work, it will return a status code and will inform
Gottleib that something isn't right about our test gripped the entire pipeline will indicate that by
failing.
Let's now add some additional tests in order to check if the contents of the file is as we suspect.
So we now have a car.
Would we want to check?
Do we have a chassis?
Do we have an engine?
And we have wheels inside.
So let's switch inside a built folder.
And what do we do next is to use the GRAP command, which can search for a specific string inside a
file.
So we're going to search for Chessie.
Inside a car, that text file.
The same goes for engine.
And the same goes for Wheelz.
Now, we haven't really specified in which order should this jobs be executed and getler by default,
it will try to round them in parallel and this is definitely something we are not interested in.
So in order to specify to order in which different jobs should be executed, we need to define stages.
So the instruction to defined stages is quite intuitive.
It's called stages.
And we'll have two stages, the stage build.
And the stage test.
Now, what we need to do next is to specify which of these jobs belong to which stage.
So when I say here before the script or even after the script, it doesn't really matter.
This will be the build stage.
And this will be the test stage.
Now let's save to file and see how the pipeline works.
One important thing to note is that Gottleib is offering information regarding this file and it says
here, this gallaccio configuration is valid and it may happen that you make some mistakes inside your
file.
You write something the wrong way and Gottleib will offer you an error and you will need to fix that
file.
So only have valid configurations will be executed by Gottleib.
This is something that happens before the pipeline is executed.
So every time you create, you make changes to your pipeline.
Gottleib will check that.
And if it's not valid, it will not even execute a pipeline because it will not make sense.
Now, let's click on the pipeline and see how it's working.
Now, right from the start, you'll see that our pipeline looks a bit different than it used to look
before, we have now two separate stages.
We have to build stage and now we have to test stage.
Belonging to the build stage is the build card job and belonging to the test stage, is this the card
job?
Of course, stages can have multiple jobs, which can run in parallel and you can add as many stages
and as many jobs as you need.
Now, after waiting a bit, you'll probably notice this, the test tube actually failed.
So let's look into it and see exactly what happened.
It seems that the first test, the test where we are checking if the file was created, fails, and
it seems indeed that this file isn't present here, this is quite normal, because what happens is that
the jobs that we are running, they are sort of independent from one another.
They do not exchange any data, if not told to exchange any data.
So the previous job, the job did something.
But we haven't specified what should happen with the with the file that was created.
So after the job terminated, all the files would basically be removed.
So the environment where the job was executed was simply destroyed and it does not longer exist.
So when the next job is starting and has no idea, it looks inside what it has inside the repository,
more or less, because this is what it's doing, is checking out the repository and then doing the steps,
being told to do and looking inside of the repository and looking and saying, well, I don't have a
car, I don't have a car that takes the file.
And as I said, that is normal.
And we need to instruct the jobs, which is our output, which is our artifact to say like that because
we are building something.
And this is something that we want to keep.
We don't want to throw it away after the process.
So let's change again our configuration and try to get that fixed.
So in order to tell the first job what to save.
We need to define the artifact.
And that is being done by using artifacts.
And of course, the artifacts need a path, so we need to specify where exactly is the artifact located?
And now we can say we can save a file or we can save entire folder.
Now let's simply make this simple and we're going to save the entire folder.
So I'm going to say here, build this is our artifact.
This is what should be saved after this job is executed.
And the rest of it is not interesting.
But what inside build?
This is what we want to keep.
Now, let's give this another try and see if it works.
You notice that every time we make a change in this repository, the pipeline is triggered and the pipeline
will be stronger, not only when we edit the configuration, file the DOT, get lab tested at YAML file,
but every time you make a change inside the repository, you -- or you edit any other file.
The pipeline will start in order to ensure that the change you have made is still properly working.
If you want to follow along with what a specific job is doing, you can simply click on it.
Now, again, you will notice and you're probably thinking, what the heck is going on here?
Why is this?
They're still not working.
And the only way to tell what is happening, why something is failing is to read the logs and see exactly
what is going on.
And you'll notice here again, the first step now appears to be working.
So now somehow the next job has this artifact, has this folder and a card, a text file inside.
It's getting inside that folder, but somehow is not finding the chassis that we have edited.
Now we can go into more debugging on why this is not working.
But the reason for this is that I have added a mistake in the code from the beginning.
Just wanted to show you how important it is to write tests that actually fail.
So I'm going to go back to the project.
And get this built fixed now.
The problem is right here, instead of spending all this, the chassis, the engine and the wheels to
the car that have replaced the entire content.
And the way we do appending is using this operator.
And now it should definitely work.
Any time you need to debugging, feel free to add commands like alerts to list the contents of the folder,
or you can use something like that and say Khadar texte.
And this will show you the contents, so anything that is needed in order to debug the problem, you
can simply edit here just as you would do it when using a normal terminal.
Every time we want to look into what has previously happened, it can go here to secede and you would
be able to see pipelines.
And you can see all the previous ones that we had so we had so far for pipelines, and this is where
we started adding the second step, the testing step, and this is actually the step where we have added
to artifact and jobs that have created artifacts are available for download.
So you can inspect the files that have been generated that way as well.
So you can easily check them here.
We'll see here artefact, but you can view them when you're looking at the job as well.
So if I'm looking at this job again.
Right here on the right side, you will see job artifacts, I can browse them.
Obviously had a built for that I have created.
And I can download this text file.
And if I were inspecting the contents of this file now on my computer after I have downloaded it, you
will see it only contains Swails because Wil's was the last step in my process and it replaced everything
that was previously there.
Going back to the pipeline, let's see if it now properly works.
And now we will see both stages are successful, so the build stage passed and a test stage passed as
well, and we can look into detail at the console output and you will see here.
The first test was successful, we can go inside to build for the, um, we can view the contents of
the car that takes the file using a cat key at command and then with grep, we are searching the contents
of this file for Chessie, for engine and four wheels.
And all these commands succeed for that reason.
The entire job is then successful.
Then this is our test on this very simple to process car assembly line.
Now, let's take a final look at the repository you will still see inside a project that only the Gottleib
pipeline definition file is available.
So the built for life that we have created, the Khadar takes the file.
They are not added to the repository.
They are created in the pipeline.
And we have decided we want to save them as artifacts.
And these artifacts are independent of the GETT project.
So for that reason, they are not committed inside of project, but they are available separately for
download or for additional steps, whatever is needed.
So this is how you can use Getler theeye in order to create a very, very simple pipeline with two stages,
we have used stages in order to define which our two stages build and test in the first stage.
We have built the car using very simple commands and in the second part we tested that.
What if we added to the car?
Text file is right and using artifacts, we have made a communication between these two steps.