by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 22 15:01
    jetersen commented #196
  • Sep 22 14:43
    janisliepins commented #196
  • Sep 22 14:43
    janisliepins commented #196
  • Sep 22 14:31
    timja commented #196
  • Sep 22 14:11
    janisliepins commented #196
  • Sep 22 13:59
    janisliepins commented #196
  • Sep 22 13:58
    janisliepins commented #196
  • Sep 22 12:45
    timja labeled #196
  • Sep 22 12:44
    timja edited #196
  • Sep 22 12:44
    timja labeled #196
  • Sep 22 12:44
    timja commented #196
  • Sep 22 11:57
    janisliepins opened #196
  • Sep 21 14:03
  • Sep 21 05:09
    dependabot[bot] labeled #195
  • Sep 21 05:08
    dependabot[bot] opened #195
  • Sep 21 05:08

    dependabot[bot] on maven

    Bump mockito-core from 3.5.10 t… (compare)

  • Sep 20 15:31

    timja on master

    fix typo in updating plugins se… (compare)

  • Sep 20 15:31
    timja closed #194
  • Sep 20 15:03
    feteu opened #194
Kristin Whetstone
@kwhetstone
:+1: will look at the slides!
They look good; I like including a challenges slide since that's also part of the software development process
Joseph Petersen
@jetersen
okay excluding the jenkinsci/plugin-installation-manager-tool#61
the master branch of the tool gives me a working instance but somewhat sad that I have to specify that I want the latest of icon-shim or other such plugins.
Or latest of pubsub-light without specifying it :sweat:
Natasha Stopa
@stopalopa
Ok…so the way you would want it to work would be that if a user specifies “latest” for a plugin, it would download the latest version of that plugin and the latest version of all of its dependencies by default, and if the user doesn’t want the latest version of the dependencies, they should have to specify that?
Kristin Whetstone
@kwhetstone
I think so
Natasha Stopa
@stopalopa
Ok. And is that something that should be included in the first official version?
Kristin Whetstone
@kwhetstone
Paart of me leans towards downloading latest plugins is actually against part of core of the tool. Part of the point is that it pulls in the specified versions of plugins across the board. -useLatest could be a flag to signify that that you want to download the latest version of the dependencies of ones without a version.
This is a tough one; I'm trying to think of where the behavior would most factor in.
Tim Jacomb
@timja

I wouldn't want an old dependency pulled in...
Plugins tend to have very conservative dependency versions.

But I also specify all plugins in my file so I get the versions of what I want :)

Kristin Whetstone
@kwhetstone
Yeah, but an "old dependency" wouldn't get pulled in right? The tool has already calculated the newest possible dependency
Tim Jacomb
@timja
wouldn't that be latest then?
Martin d'Anjou
@martinda
I think the way I would use this is 1) use Jenkins LTS and get all latest plugins. Then I would list the plugin versions, and create a "frozen list" with all plugin versions hardcoded.
Kristin Whetstone
@kwhetstone
Not always
Tim Jacomb
@timja
that's roughly what I do @martinda
Kristin Whetstone
@kwhetstone
That's how I thought most people were going to use it.
Which is why I thought a --useLatest flag (or some sort of config) would be a great for the other case
Martin d'Anjou
@martinda
Do you mean --use-latest instead of having to explicitely say latest for every plugin?
Kristin Whetstone
@kwhetstone
no --use-latest for downloading the latest versions of the dependencies of a plugin with version latest
The other main usecase of the tool is going to be someone saying generically "I want these plugins installed" and they might not care about versions, so they're going to just want behavior similar to how Jenkins calculates plugin dependencies today
Martin d'Anjou
@martinda
I do not know how Jenkins calculates dependencies today... does it ignore dependencies versions? Like if I ask for plugin-a:1.1.0, does it use 1.1.0 version for plugin-a with "latest" for its dependencies, or does it use the dependency versions as specified by plugin-a:1.1.0's pom.xml ?
Kristin Whetstone
@kwhetstone
Jenkins takes the latest version of everything, it doesn't respect you requesting plugin versions
Kristin Whetstone
@kwhetstone
So since in this tool, the focus has been on specific versions of plugins, I think it makes sense to download latest for dependencies of latest as an option, not the default
Natasha Stopa
@stopalopa
Ok, so it seems like we all agree that users want both the ability to control which plugins get installed as well also having the ability to get all of the latest of the plugins they specify and the dependencies if they - the disagreement is about what the default should be. I’m not sure how to make a decision. Take a vote? Reach out to the dev mailing list?
Kristin Whetstone
@kwhetstone
I'd use a flag. Let's keep it from getting too complicated. We can all vote here; give the people who have been involved early on some preference :)
Natasha Stopa
@stopalopa
It sounded like @casz wanted getting the latest dependencies to be the default and have a flag only if a user didn’t want that. Opinions @martinda, @timja, @slide or anyone else?
Alex Earl
@slide
If not specified explicitly, I would say get latest
Natasha Stopa
@stopalopa
other question about presentations from earlier - Oleg asked about the state of the library and how ready it is to be incorporated into areas. Do you guys think it looks ok or are the other things that I would need to do for that to make sure the right apis are exposed?
Kristin Whetstone
@kwhetstone
From what i could tell, the question was about making sure that the library module is separate from the CLI. Which exists as it's own separate module without any external interface today
Natasha Stopa
@stopalopa
ok. I think I interpretted it more of as a question about what methods were exposed
Kristin Whetstone
@kwhetstone
Alright, then let's look at the PluginManager class. The main thing someone would have to do to use the PluginManager is fill in a PluginConfig. Since that's using a Builder, you should be able to use the class with only defaults with just:
PluginManager pm = new PluginManger(Config.Builder.build()); // fill in additional info here
right?
The only part that could potentially be an issue is if you're in an environment where you can't write a file. Double checking to make sure the config doesn't require it for situations where you are only printing the information.
Also printing: instead of the end result being printed, I can imagine that some places might want the values returned in an array.
(map.... data structure)
Natasha Stopa
@stopalopa
oohh, on the note of not wanting to print things, we never did finish the logging PR
Kristin Whetstone
@kwhetstone
...yeah...
Natasha Stopa
@stopalopa
@kwhetstone I just changed a few more things for the project page based on some of the previous feedback: jenkins-infra/jenkins.io#2441
Do you want to take a look? As soon as that’s merged in, I will include the link in part I have to do for the final evaluation
Kristin Whetstone
@kwhetstone
Sure, I'll take a look
I think Jesse's comments about using his alternative hack for install-plugins.sh plays into the discussion about what versions of the plugins are installed by default
Using this tool to set up testing environments with consistent versions of plugins is very helpful
Natasha Stopa
@stopalopa
oh yes, definitely :) I was just about to respond to him and get his feedback
Kristin Whetstone
@kwhetstone
yay!
+1 for the GSoC team creating Meetup events, that's great!
Kristin Whetstone
@kwhetstone
It looks good. I'm a bit bummed that we weren't able to get v1 cut today
Sometimes I can be incredibly optimistic about deadlines :)
Natasha Stopa
@stopalopa
it’s not too late! I wanted to try to do it before the presentation but I also didn’t want to have to deal with all of the scramble right before presenting if it didn’t work right. I did fix everything last night that we agreed we wanted to be included in that release, I guess the question now is if we should include any of these additional things we’ve been talking about - the —latest (or —explicit-dependencies) flag, logging, ….?
Kristin Whetstone
@kwhetstone
For sure! Right before a recorded presentation is not the time for yolo releases haha
The problem with the logging is we never figured out what the message to the console would be. Appending all the extra info about class made it very hard to read if just using from the command line
And really, it would have been much harder to deal with all the local testing if the logs continued to be hard to read
Natasha Stopa
@stopalopa
Yeah, I agree we never really came to a solution. That does seem like something that we probably have to figure out before the library could be incorporated in other places though?
Kristin Whetstone
@kwhetstone
They're going to want the logger.... the problem is keeping the cli readable. :/