I just saw this, but I would be interested in working with you on this even
if it doesn't make it into GSoC.

Rick, do you need help getting a proposal started?

Best
Jeff

On Fri, Jan 17, 2020 at 3:31 AM Chris Kilding <
[email protected]> 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/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.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/CADVhPTrJQdynocY-S-LVxZzxovK151t%2BCG2Dm614m6EH_KfEBg%40mail.gmail.com.

Reply via email to