Jenkins Hacksgiving 2015, 1 Dec 2015

Previous Meeting

⏯

youtube image

►

From YouTube: Hacksgiving: Plugin Developer Open Q&A

Description

In this Hacksgiving 2015 session, abayer and a few other contributors participate in an open Q&A session around plugin development.

A

I'm kind of curious: have you you're looking at the extension points? Page yes, I am and have you looked through ever Nats deprecated? Yes, I did plug-in deprecation list.

B

Yeah, that is a pretty cool thing. I, don't have it handy, but it would be quite nice to be able to dive through and start hunting down those deprecated uses of extension points, because there are a lot of them.

B

Yeah I thought that was a kind of things I've seen recently. One.

A

Of the things that is going to ask is, if you know, Stephen referenced this page earlier as well, I'm wondering if this page is properly highlighting all of the deprecated extension points or if they're omitted and think is everything on this page usable right now, ah I.

C

Think this is pages like periodically generated, so that information should probably be should play exist, generated.

B

By the extension, finder right.

B

But yeah, that's that's a lot of deprecated API usage. We.

A

B

My take on plugin testing, best practices, I.

B

Find somebody who knows better about testing than me and get their opinion. That's my best practice. uh It's a really really good question. There is no really well-defined answer for how to best test plugins I know I'm pretty crap about the ones that I do that, aren't especially the ones that aren't public.

B

No, no! It's it's! It's a really interesting question and we have the test harness which work. So you can run a you know it your plug-in in jenkins, in a test. But what does that really mean? What exactly are we testing? It's a it's a good question.

A

B

Yeah forgot to repeat the question: was about testing best practices and now there's people poking at each other, over mockito versus Power, Mac versus Jenkins rule versus who knows what and I'm expecting Tyler to just start saying: Spock randomly.

B

Not that I see brought any of these I I have no strong opinions on test frameworks. uh Well,.

A

So if, if you look at the announcing you specifically Andrew I can look at stephens session today or yesterday, once they're posted on YouTube, they both covered some testing using DJ unit rule Jenkins rule which stands up. The stands up sort of an embedded Jenkins instance to run integration tests against. We also talked about the acceptance test harness which is on the Jenkins CI github organization, which is more for driving.

A

You know web oriented, selenium type acceptance tests through the UI and then Steven I think we may have missed it in this morning session, going through the web client integration test as well. Did we.

C

So I was muted, I yeah, so we did go over. Something called the acceptance test. Harness um is that this is like your I could very like simple. You know just similar to like a you know, unit testing in like a small type of integration testing. um Now, however, there are things like the acceptance test harness. Let me shirt, which is uh I, give you go through the wiki page. We kind of there's like some videos on how to kind of write a unit test.

C

So it's like the selenium testing, if that's kind of what you are like looking for more. This is.

A

The page that Andrew has up right now the unit test wiki page, and is this up-to-date enough for people to start in on here? Uh-Huh.

C

I think so, so this is the scroll back up, so this is 0. This is doing the web client stuff. So this was something that um I was going to kind of show a little bit by decided not to it's. um So this is kind of like doing something similar. It uses.

B

That's just one of the things that it does it's right. This covers a pretty broad array of test techniques. Oh.

C

Okay, so I see the okay.

C

So covers more that the page that I saw was the web asserts, and things like that, so I immediately thought it was the only HTML so yeah so down below it. Has you know the option to test with the plugin I know without Jenkins?

C

So you know if you have local data like a zip file that contains like the job configuration and things like that, you know it's. You can easily add those.

B

Hudson test case I, remember: Hudson, Ches Ches, that's where I started.

A

Issues receded and.

B

That was my hairline that receded I.

A

Am just for for the folks on the stream I've been keeping track of some notes and some links in the etherpad, which is etherpad, OSU OSL org, slash jenkins, dash x, giving so as we go through some of these wiki pages of adding them to that and those I'm adding to the hacks giving page at the end of the day as well. And so, if you miss something is no big deal it'll be in the notes.

A

The what might be a what might be something interesting to go through is the there's a couple of like reports and, I would say, shared resources that we have running and Jenkins on. Jenkins I mean the extensions points. Paged is generated automatically the update Center generated automatically. There's that plug-in compat job. That's running around I think there's a lot of these things floating around in the Jenkins infrastructure that can be useful to plug-in developers but are somewhat hidden.

A

B

Actually, right now.

A

These libraries is also another Gooden yeah.

B

Right well, the fact that I can't figure out where the stuff you're talking about is that's usually on.

A

Co chicken see I network. Oh.

B

That's right: we.

A

B

Over there, who can do? Aha, that's the all failed tab, so it's okay that they're all red also most of them are read most of the time anyway.

B

See ya plugging kapat tester hasn't run in three years. Let's play attention. No attention to that one, but.

C

That's I think that's where the acceptance s fine is kind of yeah. Look over so.

B

That not sure when that's running these days, Abbas.

A

Harness is running in the debit cloud instance.

B

Back over to the grad work, more tabs more tabs for the tap god.

B

And where's that plugins ah too many plugins.

C

What are you looking for? The.

A

Exception is not really so.

C

If you go, I think to core.

B

Aha acceptance tests harnessed they, it does stuff. I like it when things do stuff well, sometimes stephen.

A

Can you explain what this job does for class myself included.

C

So I think this is actually just running the, so the acceptance has harnessed what it does is on it. It does again the kind of likely click interaction for, like a specific I, think, there's like a specific set of plugins in there. That lets see like there's the subversion plugin, there's, probably like the get plug and a few other ones. They just do the like your basic. You know you I clicking um and.

C

Right so like they have like different scenarios, and you know if you click on one specifically, um you know I. Ok, so I guess this I'm sorry I.

A

Have a feeling that and I could be misremembering that this acceptance has tarnished repository and I put a link in the notes in the sidebar is used by the LTS team as well. Isn't it yes.

C

This is used by the LTS team to make sure that there's a so that the instances are right say your LTS line is, you know, passing so at least the acceptance test. You know they run on the LTS line as well.

A

D

A

Be adding stuff into the acceptance test harness repository.

C

B

That's something we should have a blog post, that I didn't even know that now I want to go write so well now you know now I know and knowing is an eighth of the battle inflation.

B

But yeah so it.

A

Looks like hit.

B

With red lasers, it looks like it's uh got some logic near for actually testing the plugin. That's kind of nice right.

C

So it's like the it tests to make sure that you know its stock I'll board. You know if its stock, you know abort if it failed or something like that. So it's yeah.

B

A lot of things.

C

B

To play with this, yeah is.

A

It possible stupid and selenium tests like this into the plug-in repository directly or should people be adding them into the acceptance test harness repository I? I.

C

Would recommend adding them to the acceptance test harness repository, yeah I did oh go ahead, so I was also going to mention too that this there are some tests in here that actually do things more detailed. So there's like docker containers that spin up ldap environment, um so you can kind of see. You know you know that it has like a very basic ldap instance, and you know we test against that.

C

So you get it right like a unit test for that specifically and.

B

Look Tyler, it's the test library you should be advocating. Given the name look cucumber.

B

You Tyler names all of his veteran all of his machines after vegetables, so.

B

He's a strange man, he is yeah, so I guess that's something. I should have looked into more before we did. This I'm gonna put that on my list of things. I need to dive into more that have really involved since I was last deeply involved, with the project day to day, because yeah I mean one thing that I think has always been a problem with Jenkins plugin and core testing is that we have a very little actual unit tests, especially in core. It's almost all test harness stuff and I.

B

Think that's I'm, not sure how bad that is, except if you want to actually say leg-up cobertura.

B

Which now that I realize that Stephen is the maintainer cobertura? Guess what you're gonna get to do? You.

D

Can use some code coverage tools with Jenkins room Oh in.

B

It actually, what will it hook up the core test stuff to core source? That's the yep, so I'm.

D

Not just some sources.

B

That used to be my the bane of my existence for about a month where I was trying to figure out a way to make that work and then ran away screaming I mean that was years ago, as.

D

Far as I know, it works, you know we have. We have it configured with jacoco for club these plugins. Well, let's.

B

Take a look at that yeah. It looks like that that I guess what I would say then is treat the it.

D

Does not work for acceptance tests well, yeah, of course,.

B

And so this is me speaking as if I have authority, anybody else can contradict me. I'd say that within the plug-in itself, focus on testing your functionality, think of it as unit tests, even if it is really true unit tests. Since you are running it in a Jenkins, will context etc, ah and they could be acceptance. Tests harnessed as the integration testing as the making sure that your plugin actually works in a specific version of Jenkins etc.

B

D

That sound other with other plugins yeah.

B

Without a play, yeah in a more developed context,.

D

Acceptance tests can also they can also test why class loading behaviors, which currently Jenkins rule, doesn't really handle properly, and it's also under for testing UI controls call there. So there are a few. There are a few kind of corner cases where acceptance tests can probe things. You can't really get at with Jenkins rural functional tests, yeah.

B

I know I have tended to avoid the the HTML unit stuff and the screen scraping and round trip configuration stuff when I've written tests, because it's kind of like well if it works when I try it by hand I'm not really going to worry about whether it works in the automator context. There's too many other things about the actual functionality that I care more about I'm.

D

Actually, they buy their rate tests. We can think of.

B

D

Better place to put it I write tests with config round-trip all the time using Jenkins rule. It's actually I'll.

B

Just talking about my personal tendencies, yeah.

D

I'm just saying first things it. Basically, anytime, you have a configuration forum, it's good practice to at a corresponding configuring trip test. This is relatively quick to run. It doesn't require you know any external, selenium setup or anything like that can be right, part of the plug-in source base and it will catch all sorts of regressions and your usage of form controls and that sort of thing. So it's a relatively cheap and effective way to prevent things from going wrong, especially if you're doing anything.

D

If you have to think for more than a second about what you're writing in the jelly file should probably be using them. I try.

B

Really hard not to have to do that. That's.

D

B

So, jumping away from the testing for a moment, the reason why the exceptions points page is my favoritest thing ever. Is this the fact that not only does it lists all the extension points, but you can find their frickin implementations, which, for me is just huge, because I can figure out what is doing something similar to what I'm don't want to do? What's where's an implementation of an extension point that I uh no I want to extend, but don't really know what that means or know what the code really would look like.

B

It's the crew giant, crib sheet and I can't live without it. What I'm doing plug and development and in the old old days when I, would just have the svn check out of the entire tree and then I just crept everything, but no.

D

You know there's some, but I would I do I mean this is great. This is perfect for finding extension points specifically, but if you're just interested in code patterns generally, it's possible to add a carefully constructed URL to your browser search bar, so that if you just go to the search bar and github tab, and then you type in some class name or distinctive function, name or something like that, it will immediately do a github search across all of Jenkins. Ci right include cloudbees. Repos too could.

B

You send that to Tyler, so I can put it in the notes. Yeah.

D

It's actually on the wiki I think so. There's a wiki page called drepung jenkins sources. I'm not sure if it specifically has a hint for the the search bar, but it.

B

D

Know that link.

B

To the very bottom and of.

D

B

The absolutely demented back end merge all repo, yes, which doesn't work about eighty percent of the time and shouldn't worry about rivers in the time, because 1100 freaking plug in repose is too much anyway.

D

If you take the last link there and delete this some class static method and just keep the rest of that URL and make em you can create, am and replace it with a think % s or something like that, then you can create a browser search shortcut which is right. It's a few minutes to do and it pays off many many times.

A

B

C

This and it's it's very powerful for that quickly, searching all the repositories I.

B

Will have to set that up because yeah that definitely does seem useful yeah. ah So one question that nobody's asked that I'm going to answer right now is: should I write a new plug-in for this thing and my answer is going to be probably not.

B

There are too many plugins that.

B

I did basically my philosophy on whether a new plugin is merited is: is there nothing that does what it does or some subset of what it does etc?

B

Then, yes, obviously a new plug-in if it's a new space or if it's supporting a new mic like it makes sense to if there's a new code coverage tool to have a new code coverage plugin. But if your functionality overlaps with another plugin, see, if you can combine your plugins see if you can find a way to work with them, the whoever's, the existing maintainer or if there isn't one ask nicely and in on the dev list, and you can probably adopt it, ought to see if you can meet your needs within the existing plug.

B

So you can contribute to the existing plugin because yeah one.

A

Of the things that I think has been an interesting development over the past two or three years, I would say: is the proliferation of library, type, plugins and I?

A

Think the the workflow sweet that that Jessie's been working on is probably one of the best examples of this to where um you know, there's there's workflow common I think it is and there's sort of a base set of plugins, and you know instead of what we used to do save four years ago, where there'd be the gift plugin, which had every single thing under the Sun not even touch get inside of it.

A

Now we have the git client, plugin and there's specific github plugins, that that tailored to specific functionalities and from my perspective and Jesse you're, definitely more experienced in this area than me. I find that the the problem is not necessarily the number of plugins. The problem is when you have two plugins, which are mostly overlapping that have wildly divergent you.

C

A

The client libraries underneath to where they're just built so differently that there's no possibility to merge them or to you know, coalesce efforts in the future Liam that I think it's been pretty cool over the past couple years.

A

B

So in that new, the cloud well now this is an old man yells at Club. This is a other variant of the theme this is the dear mr. president. There are too many states these days, uh but no I think that the the move to a library for common functionality in a thematic area is a really good thing.

B

That's uh definitely fits with some of what I'm talking about where why it doesn't make sense to reinvent the wheel for get in five different plugins that are all doing where were they all have may have twenty percent that's different, but they have eighty percent, that's the same, uh but still even then we have too many plugins plug and discovery as hard as I'm sure everybody knows, and we still end up with that overlap and duplication so think hard before you actually do your own plugin, um there's, probably a plugin.

B

You can find that already exists. That does a lot of what you want. That is abandoned that you can take over I just help. Somebody do that with the play plugin in the last week.

B

B

Any other questions, or are we just gonna ramble? We can ramble I. We've got a good shot now yer, so.

A

He could I suppose you could ramble, but there's I expected this to be a somewhat empty and more like an office hours where yeah.

B

A

Pop home and ask questions and things like that, all.

B

A

I'm gonna go dig through the devil. It's there are some some good questions that I saw last week. That may not have been answered actually.

B

I have a question Jesse. If you talk a bit about what you need to do to get a plug in supporting work flow properly and, let's just assume like a simple plug-in, it's like a rapper or a build step. Yeah.

D

There's no such thing as a well. There is such a thing as a simple plug-in, but most of the work. So there is a guide about this, which I can shell paste the link into IRC for now expediency. So this is a plug-in developer guide here it is and they're.

D

Basically what you need to do and in the simplest cases, is update the core dependency and either switch to some newer api's or stop using some deprecated api's. I mean the the single most common thing is just that: there's a more general supertype for workflow jobs and runs than is true for violin.

B

Maven and matrix they descend from run and job rather than abstract, build and abstract project right.

D

Reason for that being the abstract project and abstract build, have have a whole bunch of assumptions about a a freestyle like universe. You.

B

D

11 build slave one sem, etc. It just was a flexible in.

B

General, it's a good idea to go as far up the inheritance tree as you can before your uh before your. It object. Yes, yeah just just just as and it's I've always been an abstract builder project guy, because that's generally what I've had to worry about, but then I will run into something where it actually comes from somewhere else, and it just gets confusing so yeah. If you can use run and you can use job use, running job.

D

Yeah, that's that's the most common thing and then and then typically what happens is you make those substitutions? And then you see what doesn't compile and then you'll see some little things like Oh. Your plug-in was assuming that could call a method to get the bill, eat the Vino door, the SCM that something checked out or wear something built, and then.

C

D

To step back and think a moment, well, you know if, if my plugin were being used on three different slaves in parallel and obviously there's not going to be one note that that's doing doing a build step on, and so how do I find that instead and usually that kind of information you typically get from the workspace parameter that you get past and so on?

D

um And then there's there's a section dealing with data binding. This is not, strictly speaking, workflow specific, it's stuff. You ought to do anyway, but it can become mandatory if you want Rick flow compatibility, so basically just cleaning up all the form bindings to not use any tricks and to use consistent patterns everywhere, so that you're following conventions for everything. There's a one-to-one mapping between fields and your configuration form and getters near.

B

D

Class and suburbs.

B

Or constructor for evidence, so is there the the recommendation for plugins at this point is to only have mandatory parameters in databound constructor and do everything else in databound, setters, yep.

D

Yeah, that's the recommendation. That's nice anyway, yeah, because if you want to introduce new optional properties in the future, then you just have to add the setter and you don't have to do the little dance that people did in the past. The sequence of 12 different constructors, 11 of which are deprecated yeah.

B

This model that I I still hit that problem with a plugin that I wrote internally at the previous job that time when it went to ssh slaves, 1 dot, 10. Suddenly, the old constructor wasn't there anymore and yeah yeah.

D

Sometimes people just change the constructor and neglect to leave the hold on there, and then you get lake at your arms, not.

B

Having to change your constructor is generally a good thing.

D

So those are the probably the two biggest things and then for particular kinds of integrations. You're doing there are other little details that you need to pay attention to now, I'm well. I guess I should say for build steps and build wrappers, the the biggest change which the biggest change for some plugins for some plugins. You don't have to do anything, but the biggest requirement is that any state that you have needs to be safely serializable um so for build steps.

D

Usually this doesn't really come up because it's expected to be more or less instantaneous, but for build wrappers. This is most of the work and doing conversion in most cases, because you, because a a build, might start and run the opening block of the build, wrapper and then taken three starts and then and then it comes back up and you need to get all of your state back exactly the way it was so you can't be holding open, socket connection who are stuff like that.

D

You have to have everything in a in a format where you can safely round-trip it from disk.

B

So one question I had about this: was: how do you go from this style? You know the where you actually have to specify the class to just having it like the bash step or archive step. How do you get that it? How do you actually get your plug-in in supported by the dsl.

D

You can add your own custom step, I kind of recommend people. Don't if that, if there's not any other reason to do it, then don't do it and just wait for Chris, K and I to do Jenkins, 299, 22 I just put the link in IRC, which would do that automatically for everybody's plug-in without out your without your plug-in needing to have any workflow specific dependencies.

D

So, basically, basically that would be sort of a unification of.

D

Systems that are needed by workflow chopped dsl plug-in and the mo project plugin, so that there is a single, consistent way of referring to jenkins configuration objects from scripty places of different sorts. I.

B

Can't vote for it more than once frequently I'd love that yeah.

D

That's this has been a long-standing to do again. Yeah.

B

It's I know: we've we've had various chats over the last couple years regarding figuring out how to unify, or at least stop the confusion being, quite so bad between job dsl and workflow. Specifically, where there's did at first glance, it seems like they're the same thing: they're really not, but there's enough overlap in vocabulary shall we say or or meaning that it feels like a common. A common way to refer to things would be good, especially if we can have that getting pushed from the plug inside.

D

Is currently currently job, dsl plugin solves this by just hard coding, dsl names for everything in cornhole list of plugins, and it.

C

Works, that's nya. It's.

D

Not the way you'd like to do forever now.

B

We thought about some ways to try to have that autodiscover or to auto populate from ja, existing jobs and things like that, and it just was a giant pain. But if there's something else that can generate that job dsl can work on what use that would be fantastic. Yeah.

D

The idea would probably be to have some sort of standard, simple annotation, that core and plugins could all use to UM to define script friendly names for different things. Well,.

B

Plug out guys plugins exit through, uh if that's something you want Jenkins 2992 to vote for it, uh because I can only vote once unless I create a new user. It's not fair. Costco has like 10 users on JIRA. You could be able to vote up anything. It's true now that I think that would be really nice, because better supporting workflow and better supporting job dsl I think is the way the plugin should be going.

B

Workflow looks like it's going to keep growing as a major way to be running jobs and, alongside that job dsl, I know that there's people who are already using job dsl in combination with workflow and I, swear by job dsl for managing massive arrays of jobs for massive arrays of branches. That may differ just enough that you can't use something like the workflows, multi-branch logic.

D

Although, if that's true I would be interested in knowing the details, because.

B

It's we it's weirdly, complex stuff, there's like eight series of jobs that depend on a couple different places and variables all over the wazoo, its enterprise stuff.

D

ah But yeah yeah there's a lot of opportunities for integration between the two I think yeah.

B

Your or it's common vocabulary, I think, is the main thing. It's that they be job. Dsl does not replace work. It's not replaced by workflow. Some of what I personally have used job dsl for can be done by workflow, probably better, but that's more that the jobs that I'm either the way that my jobs are set up could be better done than workflow and job dsl is descriptive rather than prescriptive. So it's just saying what are your jobs right, yeah.

D

If there's overlap in this sense that certain kinds of advanced job configurations or job chains were always too awkward to express using the GUI, and so one solution to that is to use job dsl and physically create the same jobs you had before, but from script, and workflow provides a another way of doing that. Where that the script is the runtime representation rather than a static representation of jobs, but then there's a whole bunch of other uses of top dsl that are pretty different from that. The letter quite complimentary.

D

B

Let's see anybody else, listening have any questions.

B

All right, it's gonna, have to keep asking Jessie questions.

B

In which case, I really should just walk over to his house and ask him in person.

A

Jessie I'm kind of curious, so we've done a lot of things differently, with workflow um I'm kind of curious.

A

Why workflow has and has documentation on github and why it's checked in and whether that was just sort of a matter of fact thing or and.

D

A

An explicit decision behind it.

D

Mainly because I I just got sick of trying to trying and failing to satisfy a CAPTCHA 30 times a day.

D

One to use marked down- and it was just much much more comfortable to do it- that way. I'm looking forward to the the proposals for to a website, content, I, think that will be a lot nicer for.

A

D

A

Of the things that I've been it's you know sitting in the back of my head. To think about is the model that you have for the workflow plugin repository where there's the readme and then a tutorial and contributing, and things like that.

A

That's all like it doesn't make any sense to me for you to write that twice to have something show up on Jenkins that I, oh, but as a matter of incorporating that content when we generate the site. That would make a lot of sense to me and I think would be a great experience for plug-in developers like you just manage all of your plug documentation, just as you know, mark down in your repository as per normal and then that just gets slurped in and parented under. This is this?

A

Isn't done so don't hold me to this, but that could get slurped in under, like Jenkins. Do / plugins, /, artifact ID, and a lot of that stuff could be auto-generated to provide a good user experience and a good developer experience, but is something I identify, took notice, huh yeah.

D

That would be great and I I do like having to some extent I like having content underneath the plug-in repo, because it it makes it easy to develop addition user tweaks to documentation as part of the pull requests that are introducing the future yeah.

B

That's been really successful with the job dsl plugin.

D

Actually do that for the changelog as well, so it just usually have the release notes for a particular feature or bug fixes just prepared as part of the pull request.

D

Lots of merge conflicts ma.

D

A

A

A

Injure and move questions you could write some tests for plugins and be fun to watch.

A

A

That's what I thought my.

B

Head is not together when.

A

I willingly I think Stephen was the only one willingly writing tests at my request yesterday.

B

Now, if I could think of a specific plugin, that I had worked on enough recently to actually be able to dive in right away. That'd be one thing, but I.

C

B

You ah Christopher asked uh he's wondering if there's a way to improve and encourage feedback between plug-in users and developers. ah That's a really good question.

B

Blame Tyler, yeah yeah, it's it's it's hard to tell when you're not getting a response, whether it's because they're not actually using it or what I mean the best feedback we've got on. That is.

B

We go find a plug in to plug. In there we go, we could tell installation numbers, but not necessarily usage, I. Think there's some cheating that you can do with some early in the usage data for some plugins. If they have custom job types, we can actually tell how many job jobs exist of that custom, job type, but otherwise yeah it's it's.

B

And it's not always easy to monitor JIRA and yeah I. Don't know I'd like to have an answer for that I. Have anybody has any suggestions for how we can better get feedback from users about their usage of plugins and I'd love to hear it, but that's probably one of those unsolvable problems in a lot of ways.

B

Regrettably, it.

B

Feels like it find that out, you've actually solved a large chunk of open-source development right there.

B

Which be cool but.

C

It would be interesting if the wiki page actually had like a voting system for a plugin or like a survey, type thing.

B

So we've had discussions in the past about this kind of thing and I know Tyler's done some work along those lines, but that was years ago uh and they never figured out what to do with it. I guess and I. Don't think it ever had a large enough a set of input, because the reason why we can get this insulation state is because it's not self-reported it's automated.

B

If it's not automated it, people aren't not many people are going to.

B

Even if we had the review system or vote up or down its. You know the Amazon review problem, it's all going to be ones and fives, mainly once because it's only the people who are really pissed off, who bother to say anything, voting up and down with Tyler reviewing plugins. That kind of thing.

A

Was that I came into the end of that sentence so.

B

Chris ad asked about better ways of getting feedback from users to plug in devs and Steve brought up voting reviewing that kind of thing and I know you've done stuff in that area before, but I'm not sure we ever actually got any value out of that.

A

Yeah, so on the on the Jenkins page, like Jake at Sierra org, when you click into a changelog and part of what I think has been the problem with this form of feedback is that it has been so hidden um there's. You know a means to rate a Jenkins core releases, um and you know we might get 20 or 30 ratings for each release, which is what but I for plugins.

A

There's no such mechanism right now and Gus who I've been working with to come up with some new concepts and wireframes for a revamped Jenkins, iOS 8. He has been that I would say, adamant about providing some sort of / plugin review mechanism, I've been on the on a much more skeptical side of the fence in that I personally, don't find you know app store style or Yelp style reviews very useful in the context of a plugin, because a you know a plus one doesn't tell me much if it's applied to a plug-in.

A

It may tell me a lot if it applies to a plug-in release and it's a very sort of course level of feedback. So there's I definitely agree with your your desires, Chris on I'm, getting better feedback mechanisms from plug-in users to plug-in developers and there's not been much that I've seen. That's been really interesting, thus far.

A

That would allow us to get the right kind of feedback if that makes sense, like you know the on the IRC channel they're talking a little bit about the the anonymous usage data that can be sent along from a Jenkins master that if you opt-in from a Jenkins master to to the Jenkins infrastructure, there's I think interesting, automated reports that we could provide plug-in developers based on that information and of course it is often only so it would give you a subset of information, that's available, but it would also be aggregated data right, so it wouldn't be.

A

You know you might get like 500 reports or error reports or something like that, but getting to understand how users are using plug-in or whether functionality has been incorrect for them or whether they're focusing on different different functionality in your plugin. Then you might, uh you might expect.

A

Is it's a big, a big problem to to address yeah.

B

It really would have to be more specific to a single plugin if we wanted to get that kind of more granular usage data, again still aggregate to say well what life like Glen Christopher was mentioning the context of the android plug-in. What permutations of versions and platforms, toot cetera, are being used so.

A

This might be a question that you were Jesse could answer. Is there a? Is there a extension point for instrumenting your plug-in teleport anonymous usage data, or is that really driven just out of court.

A

D

That question make.

A

B

Fairly certain it's just driven out of core.

A

There might be something interesting we could explore like if I gave you a new extension point. That said, you know similar to the the graphite metrics framework. If I could say you know when this functionality is being used incremental counter or something like that, and that data gets sent up to Jenkins. If the users opted in to send that anonymous usage data and plug-in developers could start to instrument their own plugins, and you know if you're.

D

A

In seeing how many people are using this build step that you know, the the obligation would basically fall back onto the plugin developer. To say when this build stuff is being used increment the counter or something like that, and that might be a way forward for us just spitballin here, yeah.

D

There's already something which counts, number job types and things like ah yeah.

B

D

The stuff that can be calculated mechanically without knowing anything about the plugin there might be something plugin specific want to add they're, just as you can register an extension to the metrics plug-in to spit back, live data to a monitoring tool and can register an extension to support core plug-in to add something to support bundles, be nice to have something could register to add usage information like this.

D

B

It looks like the usage statistics is just a page decorator, uh there's nothing pluggable in it right now, but we'd have to really think about what uh we couldn't. I I would not be comfortable just adding an extension point to say: okay now this is in there I think we'd want to have specific call-outs for opting in for each plug-in since core it's more established, but in more general, but while the with the plugins that could be a lot more invasive.

B

Something to consider that.

A

So we in this session schedule not that any of that matters, because it's totally ad-hoc eight more minutes and I.

A

A

If maybe ranting about some of the Jenkins 30 stuff might be fun.

B

A

Yeah there was a lot of a lot of fun discussion on the mailing list that, like escape, said please, let's, let's address this in Jenkins ax, 3, dot 0, but like pie in the sky, really optimistic improvements that we can make to to the plug-in ecosystem. Since we're on the subject with the the usage data and I'm wondering if there's other cool things that that would be fun to talk about, storage back end was one that na you brought up yeah.

B

Short back end is my hobby horse. My windmill to tilt at that have some kind of probably optional way to store, build results. Test results the large-scale generally fairly structured data, so that you can actually query it in a meaningful way, because I've seen too many people try to use the Jenkins API as a way to do querying about test results and things like that for dashboards and slaps.

B

Then, when you've got five thousand tests in a run and you've got 16 matrix runs as part of that, and you run it twice a day and there's 80,000 other builds well yeah and what you get to that point Jake. It just eventually says no I'm going to take a while beyond bugs that have been found and fixed in terms of annoying locks, and things like that.

B

I mean it's unless it's all in memory, which it can't be, it's going to always take to some time to to gather historical data and trends, and that kind thing ah so some way to offload that that's actually more native to Jenkins and not like something like the del fiore. Analyzers attempt to do things like that. That is a good idea, but it ends up kind of going a little batty with performance issues. Sometimes I would be quite nice, so.

A

When you, when you first talked about this on the on the mailing list, yes, the first thing that popped up into my head was actually a very different problem to be solved around that to our Isaac. You know one of the big challenges in having any kind of highly available or with gannon chicken. This cluster is that you know plugins everything that goes into Jenkins home and mrs. around with a bunch of the files or Jenkins on behalf of plugins touches. A lot of files to her I was thinking. You were going down.

A

The route of like abstracting me saying: Jenkins plugins, you don't get to touch disc anymore. I will give you a storage API. If you need to persist something and then Jenkins itself would also use that. So, if I wanted to implement, you know a gfs storage layer yeah I would be able to, because I would know that nothing is going to use syscalls to get past me now.

B

That that is what I would like to see, but various people scared me off of that one I, implying that the viability of that was somewhere between mill and ultra mill. So uh so part of I wanted to target that build results and test results. Specifically. Is that that's a something that is more atomized? It's more self-contained?

B

It seemed like a good venue for that, even on its own would provide value, even if we couldn't take it further to the level that you're talking about, but it wouldn't be a good proof of concept, um but I need to pick that back up and start thinking about that. More.

B

One of the kind of stuff is there that we'd like to see and plug in dev that we don't have now or things we'd like to get rid of that. We have.

A

All that old, jquery nonsense tongue, toms, actually been Tom family has been doing some really good work in the in the modular ization of the front end, which I'm sure everybody that has built a plug-in is absolutely in love with jelly but see. We've got to come into this century with.

B

A

Technologies that we're using I.

B

Part of me wants jelly to live on forever for a cheer demented pneus, but yeah, and I love that the groovy view is really just a way of writing. Jelly and groovy.

D

I, don't think it's about loving jelly, it's about the fact if you want to be compatible with anything else, you have to you have to interact with the api's and systems are in place and that are expecting extensions to behave in certain ways.

D

We'd be kind of me at least for anything touching on config files is true. Maybe it's less true for pages they're, just you know, displaying some sort of data rear, more or less in control. For page.

B

Yeah it cwise I, don't know you eyes, I part of why I love jenkins when I got started with it. Oh so many years ago, was that I didn't have to think about a UI I could just go. Oh if I specify some things here, then it there's a oh cool. It just shows up, of course, that can lead to things like the throttle. Concurrent builds plugin UI, which never did anything the way I wanted it to, but still I.

A

Say I'm had a curious about the I'm, not sure I, fully understand the point that you're making there with with jelly I, mean it's executable XML and from the two like when I look at when I look at Jenkins like a web application.

A

There's this awkward blurring of the lines between the presentation, layer and the backend and two from my perspective, jelly is exacerbating some of that problem for the plugin developer, to where there's not a clean separation between what you would write in in jelly and what you know if I were building a new web application. I would just write some some backbone modules of JavaScript or something like that. I'm not sure I understands.

D

Right that we're not writing a new web applications, we're trying to incrementally Pat an old web application.

D

And there's just a lot of there's just a lot of places. We are not given a choice. The API states that, in order for your plugin to implement a certain extension point, you are given the opportunity to inject a block of HTML into you know that must consist of table rows into the following location and in order to interact with anything any other plugins and features it has to use the following set of of controls in lib form or whatever in a particular way.

D

So I mean it's not about jelly. It's about the whole way in which static HTML pages are hosed from bits and pieces of plugins when the application is a whole, that's really hard to leave, that's not something you can just change overnight grant, so you I mean your plugin is free to use any kind of web framework. You want four pages that it completely owns.

D

You know, if you just just have you, you would have a main panel of a side panel may be optionally and for the rest of it you can do whatever you think is appropriate, but most plugins aren't in that position. They're trying to contribute something to an existing page, so there has to be some API for what they can contribute and the API that we all da p eyes. We have, or based on of HTML, fragment contribution, rain.

A

Anything we're stuck with that forever.

D

Well, until someone's I mean until someone's clever enough to figure out interacted, you can, you can define new api's that aren't based on that model, and people can start to use them and as long as it doesn't need to interact directly with the old pages.

D

So for for things like build step, configuration or something I, don't see any any way around it for the foreseeable future, because that's just deeply baked in and that for plugins are doing more like reporting pages or sort of stand-alone you I, then they have more freedom.