5 ms·

Hi James, good to see Blue Ocean entering GA :) It has improved a lot since I last tried it. Although my team is moving towards Travis for everything except se

Hi James, good to see Blue Ocean entering GA :) It has improved a lot since I last tried it. Although my team is moving towards Travis for everything except server deployments. Pains me to say since I especially appreciate self-hosting, but Jenkins is still massively behind in everything outside of Blue Ocean. :/ For lots of things that are now basic in all CI/CD systems (email/slack/irc notifications, github login, etc), Jenkins still requires external plugins and/or a ton of setup from the really clunky UI. It's too much :( What's the plan to resolve this? Is blue ocean going to spread to the other areas of Jenkins?

i386 10y ago
Yes, this is absolutely within our mission to resolve. We've been discussing adding "high level notifications" in declarative and the editor. You can follow along at https://issues.jenkins-ci.org/browse/JENKINS-41687 https://issues.jenkins-ci.org/browse/JENKINS-41687. One thing to note about Blue Ocean is that as we bring in features (For example, better slack and HipChat notifications) we will be making the required plugins dependencies of Blue Ocean. We don't want you to have to think about plugins unless you are going outside our curated experience.
tokenizerrr 10y ago
The point of Jenkins is the powerful plugin ecosystem. Installing a few plugins is IMO exactly how it's supposed to be and not at all a burden.
- piva00 10y ago
  The problem we are facing at my company is: we have a federated Jenkins setup where each team got their own instance and my team managing Jenkins updates, etc. You don't know the pain we suffer from this plugin ecosystem. Installing a bunch of plugins which depends on a bunch of other stuff, there's no real dependency management for this and it's thoroughly painful when one of the teams decide to upgrade one of their plugins and break their whole setup because of it. It has happened before even with basic plugins like "Git", one upgrade completely broke more than 50% of our instances (we are running about 50 instances right now) because a lot of other plugins relied on it and then needed to be upgraded, these upgrades then broke other plugins which depended on them and this started a domino effect. Also, some plugins are just released and never taken care of, we have to maintain about 10 forks of plugins because there's no curation about them. We came to the point where Jenkins flexibility by itself is a liability. I know that Jenkins is wonderful for smaller teams but there's a point where the lack of governance really hurts and it's the main burden about it. But of course, that's a given for any flexibility, too much of it and you have to design boundaries to contain problems... I'm just ranting because after this stint I'm burned about Jenkins, to the point where I don't want ever in my life to have to work with or use it.
  - tokenizerrr 10y ago
    You can manage plugins by dropping jar files in the plugins folder. It sounds like you have 50 teams with their own Jenkins which they have administrative control over, leading to chaos. This doesn't surprise me. Have you considered letting your team also manage the plugins and locking them all to a specific version?
    - piva00 10y ago
      Exactly this, we let they have full administrative power before because each team had their own little collection of plugins they needed and we couldn't manage the migration out of the "big" old master while also having to curate their plugin collections. Our current discussion internally is about where to set their boundaries, remove administrative access and curate a set of plugins we are comfortable with maintaining (and that makes sense for most of the teams).
  - mschuster91 10y ago
    > You don't know the pain we suffer from this plugin ecosystem. Installing a bunch of plugins which depends on a bunch of other stuff, there's no real dependency management for this and it's thoroughly painful when one of the teams decide to upgrade one of their plugins and break their whole setup because of it. That problem is called Java package management, Maven just plainly sucks compared to composer and npm. At my company we solved the problem relatively easy though: a Docker image that compiles in all the plugin jars (it downloads them via mvn). Upgrading is usually easy (you just write the new version numbers from the "Available updates" screen into the pom.xml), but sometimes does takes one or two hours of wrestling when you have plugins that introduce new dependencies (which mvn cannot detect).
    - neves 10y ago
      Why mavens sucks? What are its weakness?
  - solatic 10y ago
    The core plugin system is painfully broken. It's like kernel panics: if an application causes the kernel to panic, then the more fundamental bug is in the kernel, not the application. If upgrading a plugin through the UI can cause other plugins to break because of mismanaged dependencies, then that's not really a bug in the plugin, but in the plugin management scheme. That Jenkins does not forbid administrators from upgrading through the UI plugins which are fixed dependencies of other plugins without at least a warning message about the possible damage to the instance, is a critical defect, one that has gone unfixed practically since the creation of the tool. And so it is a defect which should immediately disqualify the tool from consideration in any large environment where the need to maintain critical updates (security etc.) while keeping uptime high is crucial.
- developer2 10y ago
  I think the issue with a plugin ecosystem is that far too many 3rd party plugins do not respect the workflow of the core system that users expect to encounter - the UI appearance and functionality can easily confuse users, or even completely destroy the experience. Plugin integrations are often so poor that they ruin the product as a whole; particularly whenever a "top 10" plugin has serious bugs or flaws that prevent it from providing what a user really needs. Half-baked plugins that users depend on as a necessary evil are rarely a good thing. There is a reason that important functionality must be officially integrated into the platform: the core system must be presented as a unified and consistent interface. Community plugins can be a godsend, but they can also be the exact reason why a software service falls apart.
- pswenson 10y ago
  There are many problems with the plugin ecosystem. The big ones: * Many don't work with pipelines (scm sync config plugin for example). And you don't know this until you try * Upgrading a plugin can and often does have unintended, and hard to detect problems (only way to know is to run every job and find the failures) * It's hard to automate plugin installation

i386 10y ago

Yes, this is absolutely within our mission to resolve. We've been discussing adding "high level notifications" in declarative and the editor. You can follow along at https://issues.jenkins-ci.org/browse/JENKINS-41687 https://issues.jenkins-ci.org/browse/JENKINS-41687. One thing to note about Blue Ocean is that as we bring in features (For example, better slack and HipChat notifications) we will be making the required plugins dependencies of Blue Ocean. We don't want you to have to think about plugins unless you are going outside our curated experience.

tokenizerrr 10y ago

The point of Jenkins is the powerful plugin ecosystem. Installing a few plugins is IMO exactly how it's supposed to be and not at all a burden.

piva00 10y ago
The problem we are facing at my company is: we have a federated Jenkins setup where each team got their own instance and my team managing Jenkins updates, etc. You don't know the pain we suffer from this plugin ecosystem. Installing a bunch of plugins which depends on a bunch of other stuff, there's no real dependency management for this and it's thoroughly painful when one of the teams decide to upgrade one of their plugins and break their whole setup because of it. It has happened before even with basic plugins like "Git", one upgrade completely broke more than 50% of our instances (we are running about 50 instances right now) because a lot of other plugins relied on it and then needed to be upgraded, these upgrades then broke other plugins which depended on them and this started a domino effect. Also, some plugins are just released and never taken care of, we have to maintain about 10 forks of plugins because there's no curation about them. We came to the point where Jenkins flexibility by itself is a liability. I know that Jenkins is wonderful for smaller teams but there's a point where the lack of governance really hurts and it's the main burden about it. But of course, that's a given for any flexibility, too much of it and you have to design boundaries to contain problems... I'm just ranting because after this stint I'm burned about Jenkins, to the point where I don't want ever in my life to have to work with or use it.
- tokenizerrr 10y ago
  You can manage plugins by dropping jar files in the plugins folder. It sounds like you have 50 teams with their own Jenkins which they have administrative control over, leading to chaos. This doesn't surprise me. Have you considered letting your team also manage the plugins and locking them all to a specific version?
  - piva00 10y ago
    Exactly this, we let they have full administrative power before because each team had their own little collection of plugins they needed and we couldn't manage the migration out of the "big" old master while also having to curate their plugin collections. Our current discussion internally is about where to set their boundaries, remove administrative access and curate a set of plugins we are comfortable with maintaining (and that makes sense for most of the teams).
- mschuster91 10y ago
  > You don't know the pain we suffer from this plugin ecosystem. Installing a bunch of plugins which depends on a bunch of other stuff, there's no real dependency management for this and it's thoroughly painful when one of the teams decide to upgrade one of their plugins and break their whole setup because of it. That problem is called Java package management, Maven just plainly sucks compared to composer and npm. At my company we solved the problem relatively easy though: a Docker image that compiles in all the plugin jars (it downloads them via mvn). Upgrading is usually easy (you just write the new version numbers from the "Available updates" screen into the pom.xml), but sometimes does takes one or two hours of wrestling when you have plugins that introduce new dependencies (which mvn cannot detect).
  - neves 10y ago
    Why mavens sucks? What are its weakness?
- solatic 10y ago
  The core plugin system is painfully broken. It's like kernel panics: if an application causes the kernel to panic, then the more fundamental bug is in the kernel, not the application. If upgrading a plugin through the UI can cause other plugins to break because of mismanaged dependencies, then that's not really a bug in the plugin, but in the plugin management scheme. That Jenkins does not forbid administrators from upgrading through the UI plugins which are fixed dependencies of other plugins without at least a warning message about the possible damage to the instance, is a critical defect, one that has gone unfixed practically since the creation of the tool. And so it is a defect which should immediately disqualify the tool from consideration in any large environment where the need to maintain critical updates (security etc.) while keeping uptime high is crucial.
developer2 10y ago
I think the issue with a plugin ecosystem is that far too many 3rd party plugins do not respect the workflow of the core system that users expect to encounter - the UI appearance and functionality can easily confuse users, or even completely destroy the experience. Plugin integrations are often so poor that they ruin the product as a whole; particularly whenever a "top 10" plugin has serious bugs or flaws that prevent it from providing what a user really needs. Half-baked plugins that users depend on as a necessary evil are rarely a good thing. There is a reason that important functionality must be officially integrated into the platform: the core system must be presented as a unified and consistent interface. Community plugins can be a godsend, but they can also be the exact reason why a software service falls apart.
pswenson 10y ago
There are many problems with the plugin ecosystem. The big ones: * Many don't work with pipelines (scm sync config plugin for example). And you don't know this until you try * Upgrading a plugin can and often does have unintended, and hard to detect problems (only way to know is to run every job and find the failures) * It's hard to automate plugin installation