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
Natasha Stopa
@stopalopa
Also, since it will be hard to change them after the first real release, how do you guys feel about the cli option names? Some of them are kind of long…or do you think they’re ok?
Joseph Petersen
@jetersen
@stopalopa oh ya -h and --help is missing :D
Natasha Stopa
@stopalopa
ok, I can add those
Joseph Petersen
@jetersen
but other than that. Most of the time I suspect scripts will be running the commands so option length doesn't really matter
Natasha Stopa
@stopalopa
@casz RE: PR 61 Honestly I had also been thinking about adding another CLI option where users could specify that they wanted the latest of all plugins and their dependencies. I think right now they can specify that they want the latest version of a particular plugin but the version of the dependencies that are downloaded are dependent on whatever is in the update center metadata, which might not be the latest. Thoughts?
Joseph Petersen
@jetersen
both for yaml and plugin.txt it should be very easy to assume latest if version or second position in split is not provided :)
you could also add --update-version-to-latest which will find the newest version and put it into the file for you
Natasha Stopa
@stopalopa
I guess my question is, how important is it that if you specify that you want the latest version of a particular plugin, that the dependenices of that plugin are also the latest version?
Joseph Petersen
@jetersen
Even for dependencies, I would also say the latest is :+1: that's mostly how plugins.sh worked.
but that's my opinion :sweat:
I'd prefer to deal with the problem upfront instead of months or years down the line.
Natasha Stopa
@stopalopa
I think that was also one of the issues with install-plugins.sh - people wanted a little bit more control of the plugin versions that got installled.
Joseph Petersen
@jetersen
But it shouldn't be too hard to add the option to download latest dependencies as well :)
Kristin Whetstone
@kwhetstone
Right, the whole point is people wanted more control so just downloading the latest version isn't very helpful
:+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