Hi. I've been working on some ideas pretty similar to all you are suggesting here. The ultimate goal is, sort of: * Allow to have a Jenkins ready with all stuff in a single click or command. Or compared to IKEA: avoid having to mount the IKEA furniture manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka plugins) and people usually don't know what to use to get their furniture mounted :-) * Allow people to share "their Jenkins", meaning Jenkins version + plugins + sample-running jobs + configurations (but credentials) to allow community to reuse them. Some projects have contributed to allow that without too much effort, like JCasC, custom-war-packager, ... * Allow people to kind of vote for packages to be able to find out the most mature or relevant among all existing. * Have a centralized and easy to maintain repository of such "Jenkins configurations". It could be as easy as a GH repo with a certain template (readme + configuration file + assets), although some features like voting may be missed.
Beyond the specific proposal I made I find there are a lot of people thinking on the same problem and slightly different solutions. So it would be great to align efforts on the same direction to extract the most from us to achieve something deliverable in a short time. Not sure under what umbrella we could do that, GSoC, JEP, ... though. Best regards. On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding < [email protected]> wrote: > Jesse - cheers for pointing out the previous AWS packaging attempt, I will > take a look. > > Re version pinning, if this can’t be done in the POM, are there any > Jenkins tools which can do this, apart from the cloudbees assured update > feed? (I’m thinking of how we could support users on Jenkins community > edition.) > > Re what gets included - we could insist that any plugins included in a > cloud vendor metapackage meet certain criteria, so that they can play > together better: > - They must be able to no-op if the user doesn’t need them (ie their > default is to quietly sit on the Jenkins server and not do anything, until > the user configures them). > - They must all use the same cloud provider SDK artifact (probably the > Jenkins re-packaged HPI version of the SDK). > - If appropriate, they must all take their baseline configuration from the > same cloud provider ‘global config’ plugin. > > Re pre-defined packages - I would certainly like to see the cloud vendors > get more involved with supporting their respective Jenkins plugins. > > Chris > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.com > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAHHyvkM2xJjf90UsYyeeQJGxjH%2Buc59XoJRFXchf%3DLHs-h5Rng%40mail.gmail.com.
