Hi Rick et all, Would it be possible to submit the project idea to https://jenkins.io/projects/gsoc/2020/project-ideas/ ? We have dozens of students reaching out through different channels, and it would be great to have this idea posted so that they can review and explore the idea.
Thanks in advance, Oleg On Friday, January 17, 2020 at 12:31:42 PM UTC+1, Chris Kilding wrote: > > The notion of a Jenkins distribution(s) sounds relevant to us. > > In my company we have a central team which is trying to put together a > standardised Jenkins template to deploy on AWS, which all product teams can > then adopt instead of rolling their own. (This is part of a phased > deduplication strategy and isn't the end game: I could perhaps see a > multi-tenant central Jenkins instance for some tasks in the future.) > > The work that the central team does in assembling a set of plugin > versions, configuration etc, certifying that they all work together, and > then repeating this certification when things change, starts to look like > the work that the community around a Linux distro does. But unlike the > Linux community, Jenkins tooling teams can't share the workload with teams > in other places. Each organisation must duplicate the effort of maintaining > their own in-house Jenkins distro, even if a lot of those distros look very > similar to each other. The exception to the rule is Jenkins X for > Kubernetes, but if a company is not in a position to move their CI/CD to > Kubernetes then they're out of luck. > > For example, I suspect that both my company and Jeff's team at GoDaddy > have developed variations on a "Jenkins for AWS" distribution, but we've > reinvented them - and continue to maintain them - independently. If we were > instead to share the work of building a standardised Jenkins for AWS > distro, it might look a bit like this: > > - Start with Jenkins vanilla > - Build in a set of core AWS-specific opinions (build agents must be > spawned on [AWS compute service], logs must be forwarded to [AWS logging > service], credentials must be stored in [AWS secrets service] etc). These > would be the defining characteristics of the distro, something like how > Ubuntu uses Gnome, SystemD etc. All plugins and config required to make > this work would be pre-packed in the distro. > - Still allow users to configure this as they please, or to install extra > plugins etc. This is how they'll customise it to their environments. The > analogy with Ubuntu is that you would expect to install say language > runtimes or apps from the APT repos as those are extras, but you wouldn't > expect to replace the bundled desktop environment (you'd certainly have an > uphill struggle to do it cleanly). > > Anything that would help Jenkins users to reduce duplicated maintenance > effort sounds good in my book. Whether that's a customisation service, or > something more pre-packed equivalent to a Linux distro, or something else, > I don't have a clear picture of yet. > > I suppose the cost/benefit comes down to: > > - How much we can share > - How many teams that use Jenkins are interested in participating > - How difficult it is to build the common packaging tooling (can we do it > in 1 GSoC or is it a bigger thing?) > - Time horizons (do the potential participants foresee sticking with their > Jenkins deployment stack, or something similar to it, for at least N years > such that it's worth putting the effort in) > > Chris > > On Thu, 9 Jan 2020, at 12:36 PM, Daniel Beck wrote: > > > On Wed, Jan 8, 2020 at 3:49 PM Rick <[email protected] <javascript:>> > wrote: > > For many users, they download Jenkins first, then select some plugins and > config them. It might take a lot of time, like hours. But if we can get a > perfect Jenkins distribution which contains all we need, it can save that > time for us. Yes, I propose an out of the box solution. > > > Jesse brings up some potential issues with something like this in > https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ -- > this could require some work on a fairly badly documented and tested part > of Jenkins core to make work well. > > > -- > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- 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/903a4f91-d290-4d66-b22c-13ac031597b8%40googlegroups.com.
