[GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick
Hi team,

I'd like to share an idea with you. There are some original discussions from the GSoC thread here.

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.

The service could be like this, a website offered as https://customize.jenkins.io. Plus, it should be self-host. People can select the following configurations:
  • Jenkins core version
  • plugins
  • common configuration, user/password, update-center site e.g.
  • plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
  • multi-form package, jenkins.war or docker image
  • other things
Two projects are expected backend and frontend. I think https://github.com/jenkinsci/custom-war-packager already did a lot of works. We can reuse it in this project. The backend should provide the modern Restful API. We can start the backend project with SpringBoot, it can save a lot of time.

About the frontend project, I don't have too many experiences on it. For example, we can start it by React framework. If you're instrested in it, please help to add more ideas on it.

Any feedbacks are very appreciated.

Best regards,
Rick
--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Matt Sicker
Sounds like an interesting project idea. For inspiration on UI, would this be similar to, say, https://start.spring.io/ ?

On Wed, Jan 8, 2020 at 8:49 AM Rick <[hidden email]> wrote:
Hi team,

I'd like to share an idea with you. There are some original discussions from the GSoC thread here.

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.

The service could be like this, a website offered as https://customize.jenkins.io. Plus, it should be self-host. People can select the following configurations:
  • Jenkins core version
  • plugins
  • common configuration, user/password, update-center site e.g.
  • plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
  • multi-form package, jenkins.war or docker image
  • other things
Two projects are expected backend and frontend. I think https://github.com/jenkinsci/custom-war-packager already did a lot of works. We can reuse it in this project. The backend should provide the modern Restful API. We can start the backend project with SpringBoot, it can save a lot of time.

About the frontend project, I don't have too many experiences on it. For example, we can start it by React framework. If you're instrested in it, please help to add more ideas on it.

Any feedbacks are very appreciated.

Best regards,
Rick
--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com.


--
Matt Sicker
Senior Software Engineer, CloudBees

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyntgMxch8Pm_QhHFMpB34PUrG756iHG5kFb95WWokJEA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Sladyn Nunes
Actually Spring boot is pretty weak on the UI side it wasn't meant for that, it's more of a backend platform, but if we combine its features with a Javascript UI of our choice, it should work pretty well. 

On Wed, Jan 8, 2020, 11:14 PM Matt Sicker <[hidden email]> wrote:
Sounds like an interesting project idea. For inspiration on UI, would this be similar to, say, https://start.spring.io/ ?

On Wed, Jan 8, 2020 at 8:49 AM Rick <[hidden email]> wrote:
Hi team,

I'd like to share an idea with you. There are some original discussions from the GSoC thread here.

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.

The service could be like this, a website offered as https://customize.jenkins.io. Plus, it should be self-host. People can select the following configurations:
  • Jenkins core version
  • plugins
  • common configuration, user/password, update-center site e.g.
  • plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
  • multi-form package, jenkins.war or docker image
  • other things
Two projects are expected backend and frontend. I think https://github.com/jenkinsci/custom-war-packager already did a lot of works. We can reuse it in this project. The backend should provide the modern Restful API. We can start the backend project with SpringBoot, it can save a lot of time.

About the frontend project, I don't have too many experiences on it. For example, we can start it by React framework. If you're instrested in it, please help to add more ideas on it.

Any feedbacks are very appreciated.

Best regards,
Rick
--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com.


--
Matt Sicker
Senior Software Engineer, CloudBees

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyntgMxch8Pm_QhHFMpB34PUrG756iHG5kFb95WWokJEA%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAC-LeqsHQL71HCuefGVNqAVYQ--xvzfVFeZs8D2jX%3DfY6RpprQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick
I agree with you that Spring boot can be the framework of backend.

start.spring.io is a great example. But I afraid that Jenkins one might take a longer time. And the size might be bigger.

On Thu, Jan 9, 2020 at 1:51 AM Sladyn Nunes <[hidden email]> wrote:
Actually Spring boot is pretty weak on the UI side it wasn't meant for that, it's more of a backend platform, but if we combine its features with a Javascript UI of our choice, it should work pretty well. 

On Wed, Jan 8, 2020, 11:14 PM Matt Sicker <[hidden email]> wrote:
Sounds like an interesting project idea. For inspiration on UI, would this be similar to, say, https://start.spring.io/ ?

On Wed, Jan 8, 2020 at 8:49 AM Rick <[hidden email]> wrote:
Hi team,

I'd like to share an idea with you. There are some original discussions from the GSoC thread here.

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.

The service could be like this, a website offered as https://customize.jenkins.io. Plus, it should be self-host. People can select the following configurations:
  • Jenkins core version
  • plugins
  • common configuration, user/password, update-center site e.g.
  • plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
  • multi-form package, jenkins.war or docker image
  • other things
Two projects are expected backend and frontend. I think https://github.com/jenkinsci/custom-war-packager already did a lot of works. We can reuse it in this project. The backend should provide the modern Restful API. We can start the backend project with SpringBoot, it can save a lot of time.

About the frontend project, I don't have too many experiences on it. For example, we can start it by React framework. If you're instrested in it, please help to add more ideas on it.

Any feedbacks are very appreciated.

Best regards,
Rick
--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com.


--
Matt Sicker
Senior Software Engineer, CloudBees

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyntgMxch8Pm_QhHFMpB34PUrG756iHG5kFb95WWokJEA%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAC-LeqsHQL71HCuefGVNqAVYQ--xvzfVFeZs8D2jX%3DfY6RpprQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTEaQPd1WXLG0SDohM-Lg7BHycxyB_yN_BSzGUh0BxuX4A%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Sladyn Nunes
I am unsure about Jenkins being a bigger one because IMO that would depend on the infrastructure we use rather that on the limitations of the language.

On Thu, Jan 9, 2020, 7:17 AM Rick <[hidden email]> wrote:
I agree with you that Spring boot can be the framework of backend.

start.spring.io is a great example. But I afraid that Jenkins one might take a longer time. And the size might be bigger.

On Thu, Jan 9, 2020 at 1:51 AM Sladyn Nunes <[hidden email]> wrote:
Actually Spring boot is pretty weak on the UI side it wasn't meant for that, it's more of a backend platform, but if we combine its features with a Javascript UI of our choice, it should work pretty well. 

On Wed, Jan 8, 2020, 11:14 PM Matt Sicker <[hidden email]> wrote:
Sounds like an interesting project idea. For inspiration on UI, would this be similar to, say, https://start.spring.io/ ?

On Wed, Jan 8, 2020 at 8:49 AM Rick <[hidden email]> wrote:
Hi team,

I'd like to share an idea with you. There are some original discussions from the GSoC thread here.

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.

The service could be like this, a website offered as https://customize.jenkins.io. Plus, it should be self-host. People can select the following configurations:
  • Jenkins core version
  • plugins
  • common configuration, user/password, update-center site e.g.
  • plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
  • multi-form package, jenkins.war or docker image
  • other things
Two projects are expected backend and frontend. I think https://github.com/jenkinsci/custom-war-packager already did a lot of works. We can reuse it in this project. The backend should provide the modern Restful API. We can start the backend project with SpringBoot, it can save a lot of time.

About the frontend project, I don't have too many experiences on it. For example, we can start it by React framework. If you're instrested in it, please help to add more ideas on it.

Any feedbacks are very appreciated.

Best regards,
Rick
--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com.


--
Matt Sicker
Senior Software Engineer, CloudBees

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyntgMxch8Pm_QhHFMpB34PUrG756iHG5kFb95WWokJEA%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAC-LeqsHQL71HCuefGVNqAVYQ--xvzfVFeZs8D2jX%3DfY6RpprQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTEaQPd1WXLG0SDohM-Lg7BHycxyB_yN_BSzGUh0BxuX4A%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqs05H8irkwXPxWtCp%3DYde76WcjLF_mqqJXMA0%3DKYJO7Yw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Daniel Beck-2
In reply to this post by Rick

On Wed, Jan 8, 2020 at 3:49 PM Rick <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Chris Kilding
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 <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Oleg Nenashev
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="vCcQ1Q2mDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">linux...@...> 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 <a href="https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="vCcQ1Q2mDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/903a4f91-d290-4d66-b22c-13ac031597b8%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Sladyn Nunes
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/903a4f91-d290-4d66-b22c-13ac031597b8%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqs6Mq3cB0KkHN4ub7%3DY%3DygB1-1kG79i8vep0Q69eVWTvg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Jeff Pearce
In reply to this post by Chris Kilding
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.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 [hidden email].
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 | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick
Hi all,

Thanks for reaching out. Please help me to review my PR once I create it. I'll do it today. My daily routine is chaos now due to the virus. More than 9k people infected.

On Thu, Jan 30, 2020 at 10:54 PM Jeff <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CADVhPTrJQdynocY-S-LVxZzxovK151t%2BCG2Dm614m6EH_KfEBg%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTH-E6%3D437BCqUoEAjUeT28MAEdMmLymMjGapVxb_uXLXA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick
Hi all,


Please help me to do the review work, of course, any supplements are welcome.

On Fri, Jan 31, 2020 at 11:22 AM Rick <[hidden email]> wrote:
Hi all,

Thanks for reaching out. Please help me to review my PR once I create it. I'll do it today. My daily routine is chaos now due to the virus. More than 9k people infected.

On Thu, Jan 30, 2020 at 10:54 PM Jeff <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CADVhPTrJQdynocY-S-LVxZzxovK151t%2BCG2Dm614m6EH_KfEBg%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTHB3Gt_tNf3UhzszTGrPzBMuUGPkNe8WVbkCN%3DsnG57_w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Chris Kilding
Hi Rick,

At the contributors summit we discussed the possibility of introducing metapackages for certain tasks, rather than a full distro in the traditional sense.

For example, if a user uses Jenkins on AWS, they are quite likely to use several of the Jenkins AWS plugins together. They may also struggle when installing them on the same system, as the plugins may sometimes depend on different (incompatible) versions of the AWS SDK.

Rather than a full distro, a Jenkins for AWS metapackage (like the Debian/APT equivalent) that aggregates all those plugins would allow one central team of maintainers to assemble a combination of AWS plugin versions that are known to work together. Jenkins users would just have to install the metapackage.

These metapackages in turn could be consumed (and featured) by the proposed Jenkins customise service.

Thoughts?

Chris

On 31 Jan 2020, at 14:54, Rick <[hidden email]> wrote:

Hi all,


Please help me to do the review work, of course, any supplements are welcome.

On Fri, Jan 31, 2020 at 11:22 AM Rick <[hidden email]> wrote:
Hi all,

Thanks for reaching out. Please help me to review my PR once I create it. I'll do it today. My daily routine is chaos now due to the virus. More than 9k people infected.

On Thu, Jan 30, 2020 at 10:54 PM Jeff <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].


-- 
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/91a4c831-c6c8-42fc-9ea6-d7d4d5c9ed14%40www.fastmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CADVhPTrJQdynocY-S-LVxZzxovK151t%2BCG2Dm614m6EH_KfEBg%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTHB3Gt_tNf3UhzszTGrPzBMuUGPkNe8WVbkCN%3DsnG57_w%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B5ABBD35-6FE7-47BF-A9A1-985B2896CEAC%40chriskilding.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Jesse Glick-4
On Thu, Feb 20, 2020 at 9:51 AM Chris Kilding
<[hidden email]> wrote:
> These metapackages in turn could be consumed (and featured) by the proposed Jenkins customise service.

Also

https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/install/platform-plugins.json

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-mR6ShssSHEHL-f8msytS4_x6K%3DFSmaYBF6kju4gj%2Bg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick-2
Hi Chris,

Thanks for providing the advice. People usually use Jenkins as one or several specific scenes. Like you mentioned an AWS metapackage. I think we can define two kinds of metapackages. One is the pre-defined which likes AWS use cases, e.g. Another kind is that show the popular metapackages which come from the users of Jenkins distribution customise service. How do think about this?

Platform-plugins.json is a good example. Thanks Jesse!

Best regards,
Rick

> On 21 Feb 2020, at 00:33, Jesse Glick <[hidden email]> wrote:
>
> On Thu, Feb 20, 2020 at 9:51 AM Chris Kilding
> <[hidden email]> wrote:
>> These metapackages in turn could be consumed (and featured) by the proposed Jenkins customise service.
>
> Also
>
> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/install/platform-plugins.json
>
> --
> 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 [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-mR6ShssSHEHL-f8msytS4_x6K%3DFSmaYBF6kju4gj%2Bg%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F10030E1-760D-48BD-B149-7B8595596ABC%40126.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Chris Kilding
Hi Rick,

For specific use cases, perhaps we are looking more at meta-plugins than metapackages…

Meta-plugins would consist (almost) exclusively of a POM. Versions of each downstream plugin that is relevant to the use case would be pinned and controlled in the POM. Each meta-plugin release marks a combination of those plugins that are certified to work together. This takes the version testing and pinning work out of the Jenkins admin’s hands.

The various cloud providers are good candidates for meta-plugins, because every integration with a provider is typically built on the following foundational components:
- An SDK (e.g. aws-java-sdk-plugin)
- A shared configuration mechanism (e.g. aws-global-configuration-plugin)

And the cloud providers update their SDKs frequently, especially with security fixes, so the rate of dependency churn is high.


On the topic of advertising popular plugins, platform-plugins.json looks like a good in-band mechanism of doing this, and if particular use case meta-plugins are popular, they too should be advertised through it.

Chris

> On 21 Feb 2020, at 00:58, Rick <[hidden email]> wrote:
>
> Hi Chris,
>
> Thanks for providing the advice. People usually use Jenkins as one or several specific scenes. Like you mentioned an AWS metapackage. I think we can define two kinds of metapackages. One is the pre-defined which likes AWS use cases, e.g. Another kind is that show the popular metapackages which come from the users of Jenkins distribution customise service. How do think about this?
>
> Platform-plugins.json is a good example. Thanks Jesse!
>
> Best regards,
> Rick
>
>> On 21 Feb 2020, at 00:33, Jesse Glick <[hidden email]> wrote:
>>
>> On Thu, Feb 20, 2020 at 9:51 AM Chris Kilding
>> <[hidden email]> wrote:
>>> These metapackages in turn could be consumed (and featured) by the proposed Jenkins customise service.
>>
>> Also
>>
>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/install/platform-plugins.json
>>
>> --
>> 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 [hidden email].
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-mR6ShssSHEHL-f8msytS4_x6K%3DFSmaYBF6kju4gj%2Bg%40mail.gmail.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 [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F10030E1-760D-48BD-B149-7B8595596ABC%40126.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0371C77F-E9D3-48B1-BD77-D5B0C1173F90%40chriskilding.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Tim Jacomb
This used to be done for pipeline with the 'workflow-aggregator' plugin,
afaik it's not very popular though? and isn't really being maintained anymore

Any one able to provide any background? Or why this would be a good / bad idea

Thanks
Tim

On Fri, 21 Feb 2020 at 14:50, Chris Kilding <[hidden email]> wrote:
Hi Rick,

For specific use cases, perhaps we are looking more at meta-plugins than metapackages…

Meta-plugins would consist (almost) exclusively of a POM. Versions of each downstream plugin that is relevant to the use case would be pinned and controlled in the POM. Each meta-plugin release marks a combination of those plugins that are certified to work together. This takes the version testing and pinning work out of the Jenkins admin’s hands.

The various cloud providers are good candidates for meta-plugins, because every integration with a provider is typically built on the following foundational components:
- An SDK (e.g. aws-java-sdk-plugin)
- A shared configuration mechanism (e.g. aws-global-configuration-plugin)

And the cloud providers update their SDKs frequently, especially with security fixes, so the rate of dependency churn is high.


On the topic of advertising popular plugins, platform-plugins.json looks like a good in-band mechanism of doing this, and if particular use case meta-plugins are popular, they too should be advertised through it.

Chris

> On 21 Feb 2020, at 00:58, Rick <[hidden email]> wrote:
>
> Hi Chris,
>
> Thanks for providing the advice. People usually use Jenkins as one or several specific scenes. Like you mentioned an AWS metapackage. I think we can define two kinds of metapackages. One is the pre-defined which likes AWS use cases, e.g. Another kind is that show the popular metapackages which come from the users of Jenkins distribution customise service. How do think about this?
>
> Platform-plugins.json is a good example. Thanks Jesse!
>
> Best regards,
> Rick
>
>> On 21 Feb 2020, at 00:33, Jesse Glick <[hidden email]> wrote:
>>
>> On Thu, Feb 20, 2020 at 9:51 AM Chris Kilding
>> <[hidden email]> wrote:
>>> These metapackages in turn could be consumed (and featured) by the proposed Jenkins customise service.
>>
>> Also
>>
>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/install/platform-plugins.json
>>
>> --
>> 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 [hidden email].
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-mR6ShssSHEHL-f8msytS4_x6K%3DFSmaYBF6kju4gj%2Bg%40mail.gmail.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 [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F10030E1-760D-48BD-B149-7B8595596ABC%40126.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0371C77F-E9D3-48B1-BD77-D5B0C1173F90%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bic3nxaJM4hGB2jWr70%2BG2AgCenjdLaCoo60E3dNynkekQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Jesse Glick-4
In reply to this post by Chris Kilding
On Fri, Feb 21, 2020 at 9:50 AM Chris Kilding
<[hidden email]> wrote:
> Versions of each downstream plugin that is relevant to the use case would be pinned and controlled in the POM. Each meta-plugin release marks a combination of those plugins that are certified to work together. This takes the version testing and pinning work out of the Jenkins admin’s hands.

This would not accomplish your goal, since plugin dependencies are on
_minimum_ versions. A new release of one of the component plugins
(say, `aws-java-sdk`) would be delivered to update sites immediately,
regardless of what the current metaplugin POM says.

This is why CloudBees offers
https://docs.cloudbees.com/docs/admin-resources/latest/assurance-program/
as a value-add feature: the general update site publishes the latest
Maven release of every plugin without any cross-testing.

As for `workflow-aggregator`, I discourage its use since it just pulls
in various stuff without any clear criteria for what is relevant and
important. You might fare better with a pack which “supports AWS”, but
you would still need to think about which parts of AWS are important
for most users and which are not.

BTW for an abandoned attempt in this area which I think was not
mentioned previously:
https://github.com/jenkins-infra/evergreen/tree/140e2a12da772917529fb93a9e48c2c34daec1c0/distribution/flavors/aws-ec2-cloud

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3YQsE50L%2BqTnKqYFMyDrDSYbRNr_FWjFEsKZ6mK1C6Uw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Rick-2
I would prefer two types of solutions:

* pre-defined packaging. For example, AWS suite
  * the provider needs to  guarantee the quality of it and maintain it.
* users defined
  * we don’t guarantee anything about the suite. For example compatible something. We only provide the packing result

How about this? Do you think it makes sense?
On 02/21/2020 23:46[hidden email] wrote:
On Fri, Feb 21, 2020 at 9:50 AM Chris Kilding
<[hidden email]> wrote:
Versions of each downstream plugin that is relevant to the use case would be pinned and controlled in the POM. Each meta-plugin release marks a combination of those plugins that are certified to work together. This takes the version testing and pinning work out of the Jenkins admin’s hands.

This would not accomplish your goal, since plugin dependencies are on
_minimum_ versions. A new release of one of the component plugins
(say, `aws-java-sdk`) would be delivered to update sites immediately,
regardless of what the current metaplugin POM says.

This is why CloudBees offers
https://docs.cloudbees.com/docs/admin-resources/latest/assurance-program/
as a value-add feature: the general update site publishes the latest
Maven release of every plugin without any cross-testing.

As for `workflow-aggregator`, I discourage its use since it just pulls
in various stuff without any clear criteria for what is relevant and
important. You might fare better with a pack which “supports AWS”, but
you would still need to think about which parts of AWS are important
for most users and which are not.

BTW for an abandoned attempt in this area which I think was not
mentioned previously:
https://github.com/jenkins-infra/evergreen/tree/140e2a12da772917529fb93a9e48c2c34daec1c0/distribution/flavors/aws-ec2-cloud

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3YQsE50L%2BqTnKqYFMyDrDSYbRNr_FWjFEsKZ6mK1C6Uw%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/58e7c4ca.7c7e.1706fefa9c4.Coremail.zxjlwt%40126.com.
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Chris Kilding
In reply to this post by Jesse Glick-4
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.com.
12