Re: Interest in standardizing feature flags or capability negotiation in Jenkins?
On Thu, Oct 25, 2018 at 1:16 PM Matt Sicker wrote: > I'm somewhat iffy on the admin UI since toggling feature flags is an advanced > end user behavior IIRC KK & Tyler were emphatic that for Evergreen at least, selection of feature flags should not be exposed to administrators—this would be controlled solely on the backend. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr15QF2pgdF_--toW%2BMHJmo%2B6sEuwFO6BXTK9fJ2f_dEHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Interest in standardizing feature flags or capability negotiation in Jenkins?
I've been investigating what's required in order to support < https://issues.jenkins-ci.org/browse/JENKINS-21336> (tl;dr: make RUN_SCRIPTS the top most permission instead of ADMINISTER), and one major requirement I've found is that such a complex change would likely only be possible through feature flags (or by somehow coordinating the release of several plugins and Jenkins itself together). There are a handful of features in Jenkins that can only be enabled or disabled via system properties (which are also usually definable in an xml file). There is a SystemProperties class in Jenkins Core which facilitates this, but it's rather low level still. What I'd like to propose is an abstract feature flag API in Jenkins Core. This would work similarly to how alpha feature flags work in Kubernetes where you need to explicitly opt in to an unstable feature, though it would also double as the place where you can disable new features (e.g., we could gather together all the existing security escape hatches and other feature flags into this new API). This could potentially be combined with telemetry to see which features are used or not which can inform developers on when it's OK to remove a feature flag which is also important to avoid complexity overload. I believe this effort would be required in order to properly embrace the idea behind Jenkins Jolt. With a feature flag system, introducing behavioral changes becomes much easier to continuously deliver without long lived feature branches, one of the key aspects of delivering software quickly and reliably. Some other techniques like A/B testing and such may not be as relevant here since Jenkins is not a SaaS, but there are still tons of benefits to this anyways. My suggestion on a starting point would be to propose an API inspired by existing feature flag libraries such as LaunchDarkly, togglz, or ff4j. This can be backed by default by system properties and overrideable via a local config file or possibly even an admin interface to toggle them (and then restart Jenkins of course). I'm somewhat iffy on the admin UI since toggling feature flags is an advanced end user behavior, so encouraging people to blindly enable or disable flags doesn't seem like a great UX decision. I'm also curious how such an effort might be coordinated with any other related projects, though I'm mostly interested in Jenkins specifically (sorry, Jenkins X!). -- Matt Sicker 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox18hcRhB3Z9axpcBAU8%2Baxbaca-AjN_65%2BoOCK5D3J%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Failed build.
Thanks - I submitted another change and it seems to be back to normal. > On 25 Oct 2018, at 13:41, Jesse Glick wrote: > > On Thu, Oct 25, 2018 at 4:57 AM pallen wrote: >> Possibly one for infrastructure, but I can't post to that group. > > You can always file a ticket in the `INFRA` project. > >> https://ci.jenkins.io/job/Plugins/job/p4-plugin/job/master/285/ >> >> Please can you re-run the build and check the slaves - it looks like some >> sort of remoting issue. > > Looks like something interrupted the build, though I am not sure what. > I would not worry about it. Happens. > > -- > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3P8%3D7FwUTcxzu6e5f%2BXmV_ZzKu8eCTJMLTameihhJgrw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0801DD77-4849-4FE1-9332-D89A3137F971%40perforce.com. For more options, visit https://groups.google.com/d/optout.
Re: Failed build.
On Thu, Oct 25, 2018 at 4:57 AM pallen wrote: > Possibly one for infrastructure, but I can't post to that group. You can always file a ticket in the `INFRA` project. > https://ci.jenkins.io/job/Plugins/job/p4-plugin/job/master/285/ > > Please can you re-run the build and check the slaves - it looks like some > sort of remoting issue. Looks like something interrupted the build, though I am not sure what. I would not worry about it. Happens. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3P8%3D7FwUTcxzu6e5f%2BXmV_ZzKu8eCTJMLTameihhJgrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Failed build.
Hi Guys, Possibly one for infrastructure, but I can't post to that group. https://ci.jenkins.io/job/Plugins/job/p4-plugin/job/master/285/ Please can you re-run the build and check the slaves - it looks like some sort of remoting issue. Thank you. Kind regards, Paul -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/44f006c1-e3c0-45d8-85f1-4416f59aad94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
