I can ask how many of you use Jenkins.
I want to show you use Jitabla.
Okay.
I don't ask for Jitabla because everything is died now with Jitabla.
Okay.
Who uses Gerrit?
Yeah.
You use Gerrit.
Yes.
Okay.
Why in the past?
In the past.
Okay.
Yeah.
I can understand.
But let's say different proposed Gerrit and Jitabla.
Different way to regue and work with the code.
I'm not a fan of Jitabla, but just because my model of developing working is Gerrit Orient.
So...
Okay.
Anyway.
The big difference between Jitabla and Jitabla.
And Jenkins is like that you take appeals every day.
And you pay for the pills.
And this is Jitabla.
And you find until the pills kill you.
Or you go to a surgery.
Okay.
And now you can go to a surgery for eight hours.
And after that you don't need to take the pills.
If you survive.
Okay.
So this is a big difference.
Okay.
I try to get the surgery operations to have fun.
You know.
It's much more fun to get the surgery for eight hours.
And then forget about your problem.
Okay.
I'm Michael.
I'm working on a number of solutions.
I'm not really a CICB guy.
So I start 15 years ago to do something CICB just because the company needs some infrastructures.
And yeah.
Now what's coming with AI.
I've been testing this on.
So my main focus was embedded.
It's still embedded.
But in the weekend.
A lot of weekends.
Let's say today's every weekend.
I spend some time in Jenkins.
Now I do some plug-in contributor.
And of course I even contribute for wanting energy.
Plug-in for CV.
Extraction from a doctor for instance.
It's just to play a bit to see how the model was working in the wanting energy.
Yeah.
I find this communion is really fun.
The Jenkins one.
This is from my university and say that basically if you want to be an engineering,
say you need to be prepared to go around the world.
And this of course, those things are improving now.
I go with the bicycle.
So not anymore like this.
So now I move like this.
So it's quite fun.
Because I'm a CICB guy.
It's not needed.
Let's say, put it this way.
It's better to, you know.
Every, you know what is contributing to patients.
Seems that is a kind of topic that everyone knows.
But in my experience, but maybe you're lacking more than me.
The fact that in a lot of companies that,
if they have already a good release process,
is already a good thing.
But you know, not everything is moving so fast.
And you start up and you company that I've seen appearing
Yes, they use extensively.
Contributions.
Paraguay and so on.
Why we use Garrett because you know,
Jenkins is not really a system that you do contributing.
You interact with the user.
You do.
You know, you cannot,
Jenkins is only a way to our fantastic way to trigger your business.
Or to execute your jobs.
Let's say that Jenkins can execute any jobs.
It can fix any kind of infrastructure problems.
And it does not depend on any locking technologies.
It's Apache licensing.
I think that's under the end now on the continuation of foundation.
So it's quite nice.
But you can figure out an image with your fantasy.
Any kind of things that you want to have in your infrastructure.
And you need to ask if they succeed.
It doesn't exist.
It's also open source developer.
You can just create.
If it's created, you can just improve.
So that is the way why I mean this.
Yeah, the goal is, you know,
is the solution.
We want to define bugs.
We want to our cycle of developers.
We will finance on.
This is the tool that I use.
I can you can see parts on a cube.
But that is open source.
I mean, there is part of a son of a cube that is open source.
All the other things are completely, you know, open source tools.
First of all, the analysis.
First of all, the code checker.
Gerrit.
Explain.
Plugin.
With AI.
Jenkins.
Gerrit.
I plug in.
Sonar cube.
Martin most.
I think so.
It's almost open source.
So yeah, it's fine.
You can have everything that you have.
Consider the other ecosystem.
But what is maybe it's a bit difficult to start with it.
So there is not an easy.
You don't create a repository in GitHub or and you have everything's there.
And you have your GitHub actions.
You need to spend some times.
But when you spend, you have spend some times.
You have Jenkins.
So we have completely control of what you are doing.
You have continually.
You can continue to improve your pipeline.
You are not limited to any things because you have any plugins that you want.
If you don't have you create it, you have administration.
You can maintain your plugin.
You can decide to store your activity in a stream.
Whatever.
You can have your runners inside your company.
You can have runner in the clouds.
You can have runner.
Connect to the SSH.
You can have runner.
Connect to web socket.
You can run your windows.
In Apple.
Yeah.
So what Jenkins offer?
Okay.
For our my type of ecosystem.
We need to a way to trigger job with inger it and Jenkins.
I use personal use jerry trigger.
There is an implementation for jerry forge that you use.
Another paradigm to do trigger.
It's okay.
It's fine.
The problem that jerry trigger that I hope that I'm going to solve this year is to create a way to use
HTTPS for triggering event.
Much more fluidly and not all the SSH connections on it to get rid of this.
But yeah.
It can trigger.
Okay.
When I trigger in GitHub, you have the concept.
The wrong concept of pull request.
The worst things that the people create is the pull request.
Some people that create 20 patches.
And people that are only the pull request as a huge giant piece of code.
And that's not understand what is in each part of the code.
What is this patch is needed.
It's clean up.
Yeah.
Always get a long things.
They just said change change.
And this one day.
Just add a new commit on top of it.
Okay.
It's not really in jerry.
It's committed oriented.
It means that we are going to review each commit.
We can trigger builds that.
Very much each commit on your pull request.
Call it pull request.
And because you get it, we have the concept of topic.
That is a concrete number of commits that implement a functionalities.
That makes to have the same functionalities in CDI as a pull request.
So you can build the entire topics as once.
Verification build.
Or you can build single things.
So we're really quite interesting and powerful.
And there is a lot of reason that we need.
You know, our field to build each commit because we want.
Our code to be be acceptable.
And we want our code to be well-documented.
So get it help.
Improve this or enforce this to developers.
Then okay, artifact manager in Jenkins.
You can use any artifact manager.
You can connect to S3.
Personal use S3.
Then we have local resources.
You know, sometimes you need to contents between jobs.
So you have limited hardware resources.
You want to.
Then we have what do you have.
The other tools.
One energy that permit me to have any kind of analysis.
This is static analysis collection of problems.
Put on the thread page.
And so on.
Now we have recently worked with the guys that from China.
They explain a role plugin.
They were quite nice.
Was introduced to use AI to interpret it with result.
It's for free.
I mean for free.
If you take the Chinese.
Chinese AI is basically for free.
If you want to spend more money, you can take the other AI that you post.
Very expensive.
Renamex.
Because it's a log build.
I try to figure out.
How does Chinese AI works?
And there was pretty good.
Yeah.
That's why we're adopting.
Yeah.
Let's try to improve things.
Okay. You know, the things I try to just go fast here.
Because I want to give some example how the things I use it.
So code review for us is basically is a basic steps for improve code quality.
I know that now people tends to generate code by AI.
Let the code review by AI.
Let the AI inject the fixed inside the code.
So the role of the developer decides to mix.
Start to be not, but I want my in the company that people progress and
have an overview of the code should be done.
So what we're using AI is how the AI can improve the code review faces.
How the AI can down a bit.
The promise, the entry promise that a design can have when you push some code.
So, but the AI code review is, we start it to understand what can be the
I code review.
We implement a plugin.
We fork a plugin from a community, right?
Another Chinese guy that started.
And then we just recently changed in review.
I plugin is an aim.
It's not the official one in Garrett.
Because we have a large discussion.
And forget about it.
So they just have, thank you missing some very old version that we provide.
So now we integrate the length change, like Java for change to support multiple
Becend.
The same concept I implement in explainer plugin to allow us to use any AI that we want.
So the concept is very basic.
The comments that you can inject inside the, you know, the Garrett interfaces.
You can point it to the I to ask to review some part of code or to re-review the code.
The review of the code can start, let's say, automatic.
Every time that you push a change or you can be the CI that push a curve
Request on a post over the Garrett to say, okay, now review because the test will pass.
So the problem of the I, of course, is the I is like, it's like, you know, someone that in your apartment, you don't like him.
So it's someone that you find any kind of error in what you are doing.
I was cute at, you don't wish to wash, you know, the washing machine, you forget the door open.
This is the I.
It's always fine something.
I don't understand why it's possible, but okay.
So what we try to do in the company said, to try to make make sense of, let's say, say to the I, okay, this is something that we want to do.
And try to accept what is really needed because we never make, seems that it's difficult to make a repeat.
And but because our I is able to vote, is able to provide some things.
And so it's very annoying.
And I don't try to make the I able to vote minus two that the Garrett means you can not be able to push.
But the, the fact that the I can, cannot all review the code, that is one thing.
But in my opinion, if we review even your commit message over the code.
So it's what you describe, it's corresponding what you wrote.
Because it's not for me to review like I was in a company corporate.
And one guy sent me a batches of 2000 lights of code.
I said, smell something strange.
I do different.
We used W and it was 50 lights.
You would just miss up all the identical everywhere.
So I said, okay, just let it push where the four lights so code are should be there.
So it's very important that the, the commit message, the what you present is consistent with the commit message.
And this is a can be done easily by the I because the I found that your commit message not descriptive.
Your commit message, this, some part that you need to add and so on.
And we started to, you know, to continue this plugin.
We implement a lot of things.
So basically what we try to do, it's to create certain interactions.
Even we create a way to devugate.
So we have we can dynamically change the prompt.
We can dynamically change some as some parameters of the I because it's, we need to experiment.
It's in the beginning.
We are not able to figure out what, what will be needed.
So at now, we are still, you know, improving.
Recently, we, we even create a way to give a structure to the I.
So to say that you can commit in your project like AI instruction dot mark down.
So it's will analysis, it will add to the prompt.
Each project they can have is on prompt.
So we try to figure out what we can, you know, now everything is open source.
Of course, it's in generate up.
And then it's mirrored in GitHub.
So every people that love GitHub, they have there.
But you know, the main project is in generate up.
That is a way to you get it.
Then push back to to GitHub.
Yeah.
So I put some trivial example for some, sometimes you go, but,
basically, what is doing is that pointing out to the context and review it.
Now, the, the plugin is several way towards it.
It can works only on the context of the patch.
Or it can work in upload mode.
It means that it will pull things that is not known.
So if you have some see file that you have some function that it doesn't find in the context,
but you won't understand why this was changed.
It tried to pull the, the, the files that is contains the information that
is to continue to review.
It's not easy.
We have still problem to connect it to the factory for the eyes,
not trigger after testing after build.
It's still over.
Oh, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's,
it's, it's, and we've, I will be able to, to interact with the,
with the eye.
So we can ask question and we have interactive comment.
This is some, some drawback about because Gerrit,
we save each messages that is even reply as getting information.
So this can scale a lot of the memory data, the digital data,
the history of the Gerrit to maintain the threads.
But it's the same of the code review.
So the line comments also probably we have a lot of comments,
but this will ask to review.
And you can ask to review discard all the old comments that he was done before.
So yeah.
So the plug-in rom-up is very simple.
So we want to basically give the possibility to understand what was the,
the results of the test of the build.
So he has more information back to review.
And we want to integrate it on the Gerrit API,
API because they do a lot to improve in 3.13.
And we want that our comment can be a suggested change in the code.
So apply these changes.
So the user can directly apply this suggested code.
But you know, it's, it's open.
So we hope that something will, will happen.
Okay.
The testing.
Yeah.
The testing.
That will show something.
So we want to basically about a way to test our code.
So it's nice to collect the things of a testing.
But to what we, what I understand.
I'm coming from the age where people write the code.
And that's forget about testing.
The code is working.
It's perfect.
It's written.
Okay.
But now it's every people that joined the company.
Science the last six to seven years.
They were ready at the concept that each part of the code should be tested.
So we need to design the code to be testable.
And it's, it's not only this,
it's not the way to, you said, if we have this, if you don't test the code.
You know, we can buy this.
You need to design your code to be testable.
So what this, I can help is to collect all this information through the testing
and create the, the tools,
can generate the output as there was,
with describing the traditional code.
And we get this output and interpret it.
It is output through Jenkins.
And let's see how this can be done in Jenkins.
So how can Jenkins can help to run a testing?
I wish you basically how Jenkins can collect results coming from
JU, it's a unit testing.
Or how can Jenkins can provide and collect information from
tools like Lab Grid?
I don't know how much of you use Lab Grid in other integration
or for continuous integration, but okay.
It's just a way of wrapping of resources that you connect to your hardware
and we see later.
And you can create easy pipeline using Python so to test your hardware.
So that is the concept.
So what I mentioned, so we need to decide the code in order to be
testable.
So it's not important that,
recently we done some IoT design firmware with,
in the, in the Netherlands and the office in Netherlands.
And the lead decided the, the IoT in an order way
that we can generate the test for this IoT
and forever like around 79 or 80% of coverage
of the code.
And create all the abstraction that allow a lot to test
all the part of the, of the IoT.
So if we designed the code in the process,
the code in the proper way, then we can come out
with trained statistics and this can be happened
when you generate the releases.
You can have it if you have like verification build,
you can create gate, you can, if you have,
you know, everyone know that if you have unit test,
you can generate code coverage because, you know,
without unit test, you go coverage when anything.
Then you can run the mem checking, use the value grid,
and then you can, everything that you can check
at the time the CI is better to implement.
We even check documentation warnings,
semic file warnings.
So everything that can, let's say,
reduce the time to review code that is not satisfied.
Our standard should be integrated in the pipeline.
So, so we want only to review buildable patch.
So CI can run a test several big configurations
and run, because we have those, those important things
that we discuss it, that we want to build a busy capability.
So we don't like GitHub for that one, for instance.
It's one of the problem.
Then we want, if we want really to work as a GitHub
or a GitHub, we want to use topic build.
But the topic is more sophisticated than per request.
Topic is across multiple bits.
So a topic can be a change set that is in three of four
key repositories.
So when you verify an operating system,
you want to apply all the topic across two
repositories and buildable as a bundle.
So a topic is a concept that is across multiple
git and this guarantee is possible,
because you can create connection between the poor
request or between things in the different repositories.
This is the reason why I was created by Google for Android.
This is an 있다 PROoped type build at trigger.
So you have the patch set that is tricky.
Get it in the instance and the run the job and execute the test.
So nothing more.
And then this is a cities, this is a new stage view.
This is a new쟁ist stage view, a pipeline graph view
that is better now that show the steps.
You can sew the green and the steps in this
are what is going on.
going down, and this was the result up to Gerrit.
So Gerrit is constantly connecting what happened here.
You will have a notification back to your job.
Yeah, this is what happened in a standard Jenkins
unit test pipelines that there is some
then in this slide, there are some weak
that remind how to create them.
But the basic what you are trying to do is that you
want at some point to perform the test,
and then you have a parallel blocking Jenkins
that all the tests can be run in parallel,
and execute all the testing features.
Yeah, there are some examples out to use a code checker
or one again to cheat in these slides,
but I prefer you to see what to talk more about now.
What we have testing, we are unit testing,
we cannot complete things.
Now, we are not only testing films,
but we increase all the power power elements together
to cover all the things like other testing.
OK, now, the rest of the year, we started to have projects
that allow us to test hardware, so we are up to her lump grid,
that is basically, I frame us that a lot of
alokiter resources of colored places to hardware,
and then you can interact with user other
to replace it, so basically what the CI is doing is
ask for resources, if the resource is busy,
by other CI, there are other job that are running,
so the CI is waiting for the resource to be free,
and then get the resource automatically free.
So basically, there are lots of run,
multiple testing, both even the resource are partially used
by other jobs that are running, but when you have get the resources,
then you are located until the job is finished.
Lovely, there's an architecture that is basically,
it's let you to basically have several components,
what is important is to allocate, as I said, displays,
so you will have the client to disconnect to the lab grid.
A lab grid is not only used by the CI,
you can use it by any user to assess the resource
of what it devices, so we use not only to interact with CI,
but we use even to interact with the hardware.
Then we have the support, the coordinator, the clients,
very easy, the exporter is the one that has the resources,
connected to coordinate is one, all the exporter,
give to the coordinator what they have in them,
connect to it, and the client is you,
the task that the resources to execute any test.
OK, the key feature is basically the support for the hardware,
so you have serial, SSH, power manager,
social location, so it's quite easy,
because they have a lot of driver information tests.
And there are, they're not a nice things that I don't find any
a lot of testing, but I will make my things public sooner,
so that someone can start from there, I think.
Yeah, the lab grid configuration is done in a YAMFI
that you have in the nodes.
So let's see, because we have not a lot of times
this is a test example, lab grid, but I want to talk straight
forward on, OK, this is the benefits,
but I want to show some pipeline there.
So this one, for instance, this one is a kind of pipeline
that is part of the test, multiple configuration,
go to lab grid, execute all the tests.
It's not, this is the due to preparations,
then it is the running test for different architectures,
and then this can run basic hit-down, yes.
OK, that is fail, because the YFI is unstable,
the YFI test, so it's a one in that.
It's not really fail, but one gate was not passing during this pipeline.
But you can find it basically there, the pipeline.
OK, well, one of the things
that you know, all the things that I want to have in an infrastructure
is understand why my build was failing.
So now I add up what is in the G, as I said, multiple things.
Now, even the languages was added yesterday by the content of today's
goal, and this is very powerful, because we know
when a build failure is happening, and we have
a dedicated explainer or a part where we can see where
the arrow comes from, and you can find the plugin.
There is even screenshot, how should we?
Now I don't know if I have time to show you.
And yes, basically my roadmap is to integrate in pipeline
like I feel, and improve the nodes.
So what I'm doing with the I is that I need to find the steps
that you fail, but if you have parallel step, like 10 steps,
then you fail three things together, and the I should not
only take the first one.
My goal, the free, collect all the results, and give to the
OK, it failed, the unit test for this reason.
If fail, you don't know, the same check for this reason,
it failed, you know, for this reason.
So the idea is now to navigate.
If you want to improve the committees this one, it's very easy.
I go the three.
I go back to the first node, the failure, then there's
sent to the I.
And then there is a lot of useful link.
OK, sorry.