Jenkins Platform SIG, 30 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Platform SIG 2019 07 30

Description

Jenkins platform special interest group meeting July 30, 2020 with topics including:

* AdoptOpenJDK for Docker on Alpine, Debian Buster, and CentOS
* Deprecating the Docker agent images for Debian Stretch
* Extension development techniques
* GitHub App Authentication on ci.jenkins.io
* Plugin installation manager as a preview in Docker images

meeting notes are at https://docs.google.com/document/d/1bDfUdtjpwoX0HO2PRnfqns_TROBOK8tmP6SgVhubr2Y/edit#heading=h.urkdf8d59im8

A

Okay, welcome everyone. This is the jenkins platform special interest group. It is july the 30th 2020, thanks for being here today's session, we're going to talk about open action items, we'll review, adopt open jdk for docker on alpine debian, buster and santos.

A

uh Alex will talk about deprecation of docker agents, images using the debian operating system stretch, and then reshop has a question about extension development that we'll address.

A

So please to note that the meeting url has switched to the cdf zoom account and I've done all the actions for it. I have not completed the jet for docker operating system, support and platform selection rules. Yet yes I'll get to it. The docker build work, rework pr that, I believe is actually distinct from the alpine transition right from for the adopt open, jpdk transition. Yes, it was uh rather for platform. Support adopt open. Gdk is also on the table right, okay, so this one this one still is open.

A

We've still got work to do on it. It's got looks like some requests for changes from from alex and yeah good. Okay.

B

I need to look back at that one again, because um I think he has um done all the changes that I asked for so I will look at that a good day and update my review.

A

B

Right I would like to get that one in before the adopt open, jdk switch just uh um because jim's a lot of work in, and it's looking good for my side. So I'd like to do that. If we.

A

Can okay great and now the the build rework that jim did? That is just reworking current images that doesn't provide us with um with s390x image or powerpc image.

A

That's correct because um we need to switch to a doctor for jdk for us got it okay, great.

A

A

Excellent thanks. Okay, then review the alpine image update pr, and I think this one may be this is the use adopt open, jdk one yeah, okay, great all right. So this is the one that's mentioned in that next item on the agenda here and again, the action there is more review yeah and given the sequence more review of this one review and final sign off of 922.

B

Right and then I would have to um possibly do a little bit of rework on my pr adopt files, change and stuff like that. So.

A

C

It was mentioning uh I migrated jenkins fellow radar images to adopt open jdk, so the recent beta 15 release runs on the adopt open jdk. There were a few differences in packaging, for example, git etc, but in general it works pretty well.

B

I think in most of our images we manually installed it anyway.

D

B

D

B

The commands, I think, we're okay there, but that's a good thing to know.

C

Yeah also, there is an interesting image called uh adopt open, gdk, 11 gre vh alpine, which is actually just 50 megabytes yeah. Oh.

C

Yeah I tested it with rings, fell runner that works quite well. Well, I'm trying to compress my own part because edgings fell. Runner is about 200 megabytes right now, because of because of the fact that it's prototype uh but yeah. My overall experience with adoption is perfectly fine, uh all the tests etc pass without any issues and well, it's not a surprise, because sergeant also runs an adopt open gdp and we haven't noticed any problems.

A

That's very good news.

A

Excellent anything else on adopt open jdk for docker on alpine debian and centos.

A

Okay, next topic: deprecate the docker agent oops, my fat fingers deprecate the docker agent stretch, images alex yeah.

B

So as we go to switch to adopt jdk, they do not have a stretch image, um so this is right now this is for agent docker images.

B

um Most of the linux images are still using just the open, jdk base image, and so, if we move to adopt open jdk, we would not be able to have a stretch version with adopt open jdk.

B

So I propose deprecating those.

A

So debian stretch would not be included, so basically we would drop debian stretch when we switch to when we switch to adopt open jdk.

B

And I would say deprecate because um even if we stood if we keep building with open jdk, then um we've seen that those images are not updated, and so there are possible security issues um going forward in the future. So that's my reasoning behind.

B

Is because they would not be able to be updated.

A

Going forward so we would continue delivering debian stretch images, but using using the open jdk rather than adopt open jdk. Well, what there is, what? What's there now.

B

But okay, so the problem is that there are no updates to that image. So if there are security issues that come up, then that's a problem, we can't update it and so that's, why got it.

A

A

So open jdk when they release 262, for instance, 8u 262.. They did not update the debian stretch, image.

B

That's why they're steady okay, all right.

A

So that that explains why I think mine is still running 232, because it's based on the the jenkins core. Okay, thanks uh any discussion needed around the question, and it seems like it's a clear, clear thing that we should do acknowledging that we want updated images and buster has been out for a long time.

A

The next, the next release after debian stretch, has been up for a very long time.

B

So we just have to determine whether we want to unpublish those images or just leave them, as is with a disclaimer somehow. That would be the question that I would like.

C

The group to so yeah what we could do, we could actually do a final release of these images and inject the duplication warning right inside the entry point. So anyone uh who launches this image gets an error message in this year that the image is deprecated and after that here we can link them somewhere and after that we can stop shipping. The images.

A

Okay, so, oh like I wanted to be sure I captured what you said. It was final release of the images with a deprecation warning in the entry point and then then it was.

C

A

C

Stop publishing them so from other users latest or whatever. With this tag, they will get a warning whomever uses the last week. We will get a warning well false here, see again, we cannot have one version with the warning.

A

Okay, so we'd stop publishing images after the deprecation release, so would the deprecated version remain published for an extended period so that those who aren't immediately upgrading or well, I see no practical? I need to remove it.

C

Okay, all right yeah. I understand that we might want to remove it just to highlight the problem if somebody uses them but at the same time to make us unpredictable input on our automation, flows.

C

I would rather just stop publishing them. Similarly, like we did before this meaning, I guess terminology updates well for technology. We still keep publishing called images, but in principle I will integrate them.

A

Great, so any descent from the that proposal, that sounds wonderful to.

A

A

Alex particularly for you is that, okay with you, basically okay and a deprecation.

A

C

Yeah great yeah, one question to you alex. So what do we do with a dividend? Buster, because the default adopter and gtk images are actually based on ubuntu.

C

uh It's rather jenkins default image. Oh yes, right jenkins default image.

A

Adopt open, jdk buster, so they do have a buster image for adopt open jdk. Yes, okay, great.

A

Anything else on deprecation of.

A

Stretch nothing for me all right. So next was a question from rishabh richard extension, development question.

D

Yes, so uh seven trying to uh develop a new extension uh implement a new extension from an extension point uh within the git plugin and the extension I'm dev developing is in the github brand source plugin. So my question is that, while I'm implementing the extension point in the github branch source plugin, I need a class from the git plugin, which is not.

D

It doesn't exist in the existing release of the plugin and to do it locally. I I I have a simple hack of actually it's not a good hack, but I just replace the jar in the m2 depository. But what is the uh right way to? What is the right approach to do it? How would I, since it's a git plug-in, is not an external dependency within the form of github branch source? I assume it's been uh taken from the parent form uh or something like that.

D

I'm not sure how is it being added to the github gun source plugin, so how? How? What is the right approach.

A

I think I think you would want to add that dependency.

A

Add the dependency 2 to the branch source plugin that you're developing against. So on the git plugin. Add the git plugin dependency as a as an entry in its palm and then the crucial thing is use an incremental version number.

A

As the uh as the version on which you depend.

D

A

So so, if we look at, I'm gonna bring up, um let's bring up here, we'll just do it in this other window bring up jenkins here and let's look at uh the get plug-in oops. Let's look it's it's the get plug-in. You need not to get client plug-in right.

D

A

Okay, so if we, the extension.

D

Point is declared in the get plug-in.

A

Perfect all right, so if we look at the at the builds on the master branch as one example- and you can also do this with with- um should be able to do this with pull requests as well. But let's take a look here. This should have, I know, wait. A second is this failing to publish incrementals.

A

Okay, so richard I may I let's see if we can do it here, borrow one from here and okay, so it looks like I have a fix to make. I apologize for this. I'm gonna have to show you with get client plug-in. That's a good cause for embarrassment. Sorry for the embarrassment of the the demonstration I wanted to show is a complete failure, because it's not available there's a jesse glick was very kind.

A

He pointed out, look mark you're, being a little too too tricky in the build plug-in call that you're making in your broken incremental publishing. So we fixed that in the git client plug-in where you should be able to see here. We go now this, so I'm going to make this much bigger so that it's actually readable oops, okay. Okay! So when you look at the at the successful artifacts built from the get plug-in you'll see this get client plug-in.

A

You'll, see this magic here in the we actually publish the jar and the hpi every time, and this is an incremental that you can then reference in your palm.

A

So so it should be enough to reference that thing, but we've got to fix it in the git plug-in, so you can do the same either that or we have to release and I'd rather not release with a preliminary version just so that you can do development. So this notion of an incremental, let's see if I can find on jenkins dot, io.

A

Because there is a uh there are, there are good good instructions or good insights from here. We go from jesse glick on how to do parallel component development.

A

So this one is specific to to jenkins core, but it's the same thing where you grab the version id and then update your plug-in palm to use the version id based on that.

D

A

Now, now again, my apologies. This means either your first action is to fix, build plug, fix the jenkins file on the get plug-in, or my first action is to fix the jenkins file on the git plug-in.

A

It's probably better. If you do it model it after the one, that's in the git client plug-in. It will be sad. It's sad for me because I, like all the sophistication I put into that jenkins file, it does random version numbers, it does all sorts of elegant little things, but it breaks an important feature.

D

Okay, I'll I'll look into how it's been implemented in the git, client, plugin and I'll try to do it for the plugin as well.

C

Yeah for what it was, you can always deploy timestamp snapshots, which is the easiest way to get something running and demonstrated without incrementals.

A

Oh, oh, that's right! um Okay, so oleg to be more precise or to be to be more detailed there. He could just do a make um or a maven clean, install on from the git plugin directory, and then he could reference. That is that correct or tell.

C

A

Maybe okay, so alternately.

A

Use even clean, deploy.

A

Locally- and that will then then depend, then you would depend on the snapshot right.

C

Now, well, it's a snapshot, but it's a timestamp snapshot, so what it means uh that it gets deployed to the jenkins satisfactory and it will remain there for a particular amount of time. If I recall correctly, two weeks and during these two weeks, it can be referenced through from enable request in other components so that you can test it.

A

So my fear is that he probably does not have permission to deploy to the to the get plug-ins um section of the do not have.

C

To have permissions, oh okay, you can deploy uh snapshots if you're locked in towards the factory ones, so you still need to configure your environment in order to push releases, but you don't have to have release permissions to deploy snapchat.

D

Okay, even uh like, even if I don't deploy it and I build it locally in my machine, uh will the github brand source plugin, wouldn't it be able to find the uh jar snapshot jar from my m2 repository for my local development.

C

Yeah, so for local development, you can just run clean, install, so clean install is not good for testing, because clean installer is just limited to your machine. So if you want to demonstrate on ci, you need something better.

C

C

A

Okay, so collect the password from the artifactory install that password.

C

Collect passwords from artifactory, you just need to follow guidelines for oh, so it doesn't, it doesn't require any credentials at all. No, it requires your jenkins credentials, but uh they are drinking credentials. You don't have to retrieve passwords from like factory.

A

Okay, so it then place your uh jenkins password in the art in the maven settings: yeah, okay,.

A

Okay, all right and then maven deploy and you say, will last it will survive for two. It will uh last for two weeks. I.

C

Don't recall the exact uh time but yeah. It remains active for long enough time so that you can get your pr verified and even if it disappears, you can always deploy in your incremental version.

C

Android yeah. Actually I use timestamp snapshots for development because in such approach I don't have to wait for incrementals to be built.

D

C

But uh yeah it's a kind of not so official way being compared to incrementals, because yeah the most of contributors moved on to incrementals but yeah. I still remember on the previous floor.

A

That's that's great, thank you, so rishabh any questions.

D

No, I I understand what I have to do now. Thank you. So much for legend mark I'll I'll use this technique to depend on the the unreleased classes. I need to depend on.

A

Excellent yeah. Thank you. Oh like thank you very much. I wasn't aware of the alternate technique. I had never, never I'd always just done the maven clean, install and accepted. That's that's really great. Okay,.

A

Okay, any other topics for our meeting today.

C

Not for me so maybe related topic, we're switching um searching for you to use github application identification. For example, uh packaging repositories have been already switched, so it means that uh docker images and those native packages on neuron ci they authenticate as a github application, and the next step is to actually have a warning plug-in. It's already installed on sierra inside and yeah one of jsoc students casually. He is working on um integration of these github checks api.

C

This integration has been released, but it hasn't been uh yet deployed on scion, but once it's today we can, for example, publish docker scan reports et cetera, because there are standard formats which I will be supported by working singing. If I recall correctly- and definitely you can start doing things like just static analysis, so whatever for the images.

A

And that now you had mentioned that plugins need some additional additional discussion or additional approvals. Could you describe more just uh models.

C

From users, so literally it's one setting to be changed and, for example, I already changed jenkins core I'd use, github, authentication so yeah for plugins. It just impacts much bigger number of people, so I didn't implement it without additional feedback.

C

If you're interested it's in the infrastructure, millennials.

A

Yes, absolutely so my whole-hearted approval, that's that's really.

A

C

And yeah another thing, uh so if somebody is interested in advanced plugin management, I've got a staged full request from kim jacom, which includes plug-in installation managers, tool and efficient blocker images.

A

Now that one it seemed like there were some some issues that tim was still working through.

A

That plug-in installation manager needs some further changes before that's ready to go production. Yes,.

C

It has issues, but in principle, for common scenarios, for example, when you define now all plugins on the top level, it works quite well.

C

So it's once it's released, it will be available for evaluation and hopefully it will help to facilitate more feedback. So what we discussed that, basically um installation management will be shipped as preview so that anyone who's interested can try it out.

A

Great okay! So when, when we say ship this preview, does that mean that it will be in the jenkins jenkins image or do I need to use the experimental image.

C

On jenkins rankings, okay, so it's just, it won't be enabled by default. So what means the install plugin ssh script remains. Basically the same. So unless you explicitly switch to the new fall, you will be using those groups.

A

A

Any other items we should note in the in the in the meeting.

A

All right, let's call on in thank you: we've got google summer of code meetings uh presentations coming in. If I remember right about an hour right, oh, like we're, we start.

D

30 minutes.

A

D

A

Looking forward to that, oh 90., okay, so looking forward to google summer of code demonstrations later today, it'll be great.

B

Thanks everyone.

C

Yeah thanks and see you thanks.

C