Hey Rick, If you need any help in getting this project idea draft ready let me know and I would be happy to help.
Thanks. On Tue, Jan 28, 2020, 5:40 PM Oleg Nenashev <[email protected]> wrote: > 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]> 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]. >> 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/903a4f91-d290-4d66-b22c-13ac031597b8%40googlegroups.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/CAC-Leqs6Mq3cB0KkHN4ub7%3DY%3DygB1-1kG79i8vep0Q69eVWTvg%40mail.gmail.com.
