Let's take a minute to understand how exactly Gottleib works from an architecture point of view.
Not the first thing that you need is the Gittel observer, not the little observer offers you the interface,
allows you to create repositories and manage everything which is related to your project.
And everything that you do will be saved in a database.
And this is the main job of the observer.
Now, as soon as you create a pipeline, that pipeline will be managed by digital observer as well,
but it will be delegated to a so-called getler runner.
So what, Gottleib?
So what Digital Observer will do is we'll say to Getler Brunner, this is what you need to do next.
Download this image, execute the following steps, and eventually, if there are any artifacts, make
sure that you save them.
And that's about it.
So what the observer does, it doesn't do the heavy lifting of actually running the steps, but it manages
the entire process.
It makes sure that a runner is picking up this job, that output from the runner is somewhere stored
and saved and so on.
And that allows for a very scalable architecture because at a minimum, you'll have to gittel observer
and at least one Gillibrand, because without a runner, you will not be able to run any pipelines.
But in case your necessities are much higher, you can add as many get labor as needed.
So you can see it's easily scalable and it can happen at some of your power plants have really special
needs or that maybe use the pipelines only during the day, but not so much during the night or the
other way around.
So we can easily scale up and scale down the runners.
So the retexture that Giddyap has in this case is very flexible and it is definitely aligned to how
modern continuous integration, service work.
So if we look at the first job, build a car, this has been executed by a Getler Brunner and you will
see here that by default, ticketless Brunner is using an image, a docker image, Ruby inversion,
that five.
And of course, this is using this image and then it's starting.
The runner in the first step is cloning the repository that we have.
You will see it here.
And then it's starting to execute the steps it has found in the script, and the last step is once the
artifacts have been generated to upload those artifacts and says they're uploading artifacts to coordinator,
the coordinator is, in this case, the server itself, because it coordinates everything.
And then digital observer knows about these artifacts.
And then the job succeeded.
And after the job was successful, this runner is stopping this task.
So as soon as this has finished, the image is being destroyed and nobody else will ever have access
to it.
And the only thing that is being saved are this logs, which you can then later inspect and understand
what has happened.
And of course, the job artifacts, which you can download and inspect.
Since I talk about runners, let's have a look on how the runners are currently configured.
So if you go to your project settings, see ICD.
Would be able to find a setting regarding runners, and currently the project is running on schedule
runners, and they are actually at this moment, eight available shared runners.
Notice said runners are provided by Guillebeau itself and are available for everybody using guillebeau
dot com.
So you can see here just runners, but you can have the possibility of specifying your own runners as
well if you need more power.
So you can still use clap dotcom, but have your own runners.
And for instance, maybe you are doing some very intensive GPU work in your tasks and shed runners are
maybe two too small for what you need and maybe would like to have your own runner, which has some
characteristics which are specially designed for the kind of jobs you are running.
And then you can define such specific runners and even say this kind of job, this project needs to
run on these runners so that one runner is only used for something and the other runners can be available
for other projects and stuff like that.
So it's really flexible on what you can do on these runners.
So this is a very short overview of the Gottleib architecture and what exactly happens once a pipeline
has been started.
How is the code being executed and how everything fits together?
And hopefully any terminology you will find while using get left dot com will be now a bit much clearer.
And you will understand, at least at this level, what is going on.