Jenkins June 2021 Contributor Summit, 25 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: End User Panel Andrey Babushkin

Description

Jenkins Contributor Summit June 25, 2021 End User Panel - Andrey Babushkin

A

Yeah hi, my name is andre babushkin and currently I work for intel in intel open. We know to keep projects uh and we use jenkins. We use jenkins since the inception of our project.

A

As far as I remember, it's 2018 and the oldest jenkins version I was able to find, is 2.89 or so so we have seen uh many updates uh we've seen uh how jkusk was created, we've seen ui improvements.

A

We I think we have upgrade issues only once, and I can't remember when it was last time. So this part of jenkins is very, very great and most of user experience issues I think, is connected with the fact that opening is not a java project right. So we don't have any java experience, and you know when something goes wrong with jenkins or in jenkins pipeline. There are huge stack traces, mentioning some strange concepts. Some.

A

Deep inside pipeline csp code and that's a bit confusing other issues we have like our pipelines is such big that we was forced to split them into a few separate jobs, because we can just put all uh stages in a single pipeline uh use, spiral, step and run all builds on all linuxes, on flavors, on windows and on mac and run tests, because when you try to upload test results to jenkins build, it puts like we there's no way to uh separate few uh test executions in this in jenkins test report and other issue is sometimes we need to um more powerful build dependencies than just upstream downstream relationship right.

A

We sometimes we want to specify that this build is dependent on from this build, and this build- and uh currently we cannot do this in uh our multi-drop pipeline right.

A

So, basically, that's all that I was thinking of a few day for a few days after uh end user, if you ux panel announcement, so I think that's all.

B

It's uh nice examples um and yeah. Maybe a few quick questions before we move on so for splitting executions and test reports. Have you seen the new code coverage, api plugin.

A

uh I'm may have seen, but I had a chance to try. It.

B

Yeah so yeah, why I'm asking because it actually supports speaking reports by various factors and tags and programming languages if you want so if the user experience today is what you would like to see, maybe it could be a good referral uh for indonesia. I believe that the unit plugin currently uses github issues and team, who is on the call she's, currently one of the maintainers of the g-unit plugin, so.

A

Yeah, but like test reports is just one example of why we need to split our jobs out by planning to a few jobs right.

B

A

Other thing is uh uh amount of logs. We need to see and, uh like we've tried to put this into one big pipeline, um but, like just imagine, you have uh parallel steps with ubuntu, centos, uh debian and windows and mac os and inside each parallel stage. You need also parallelized uh test executions right and we actively use blue ocean for visualizations to see logs and when you try to use parallel stages inside parallel stages. uh It just show it just shows you nothing.

C

A

C

If you use the classic ui, the junior report will show you reports by stage and group things by stage, so you can actually have a slightly better overview. um I still don't think it's going to be great for what you want, but it might be much better than blue ocean for you.

A

ah No blue ocean is actually better because in each uh of b of build jobs and test jobs, we split out by playing a few uh for a few stages like uh copy artifacts, uh unpack artifacts run tests right results, something like that, and if we see this in classic ui, we just see the latest stage and in the later stage.

C

I'm I'm not talking about the stage overview or anything like I'm purely talking about the test result reports as in. If you go to the uh build slash test report, you will get kind of um I'm just trying to pull up an example on my instance, so I can tell you exactly rather than just going. I think it works like this based on my memory.

C

So if you bear with me for two minutes.

C

Or hopefully, less than that.

B

While we talk about that about the job relations, uh what did you expect something like a dependency graph or how would you like the jobs to be executed? What's your main problem with the current triggering.

A

uh Actually, I I think, uh like I saw uh a gig up actions pipeline recently and uh in github actions we can specify uh a stage dependency dependencies that depends from two or more stages, so this stage will be executed only after all stages, it depends from will be executed. So something like that.

B

Yeah, so basically, I think yeah. So when you define target milestones like a make file and you don't really care how what's that or the execution of targets, so it's quite a popular topic.

B

Personally, I think that um zink's pipeline engine supports it in principle, but it requires a significant uh rework of how our decels implemented so right now there is no way to actually implement them jenkins. You can just have parallel jobs, which well basically start from very beginning. Then you could probably use a join or milestones plugin to actually do some dependencies, but it would be quite complicated.

A

We actually have tried to use, uh I don't know the name of the plugin, but uh it has added a stage like awaits or something like that, but it seems there was some bug in this plugin and we have received some deadlocks in our pipelines, so we stopped using that, but actually we use jenkins not only for continuous integration purposes. We run many many uh tests in our nightly and weekly validation cycles uh and our weekly cycle is about 3 000 jenkins bills, and it's quite a lot.

C

Yeah now the the classic test results are exactly the same as the blue ocean test results in that it only shows you grouping if a test has failed, um so you get the full stage name. So apologies about saying it was better than blue ocean. It's not the same for.