Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-34002

Means of declaring a Pipeline's plugin requirements

      While a traditional project's config.xml can simply be inspected for plugins it is using, which is useful for example to ensure that the project is not loaded in an inappropriate server, this is not true of Pipeline scripts—steps it uses might be defined in various plugins, or metasteps like checkout might have configuration which refers to various plugins.

      There should be a way for the job itself to declare which plugins it wants loaded. The simplest approach would simply be a step which fails if some of the requested plugins are missing or too old:

      requirePlugins ['junit@1.6', 'parallel-test-executor']
      

      However as this is logically part of the job configuration as a whole, rather than something to be executed at a particular point in the build, it might make more sense as a JobProperty; a build started with missing plugins would immediately fail with an informative message. Using a property does not preclude defining the list from the script itself, using the properties step.

      The configuration form for the property or step could use JENKINS-31582 to inspect the last build and suggest which plugins to list.

          [JENKINS-34002] Means of declaring a Pipeline's plugin requirements

          Jesse Glick added a comment -

          -1 on a generic require step. See JENKINS-28718 for the case of tools.

          Jesse Glick added a comment - -1 on a generic require step. See JENKINS-28718 for the case of tools.

          R. Tyler Croy added a comment -

          jglick I don't see how my proposal and JENKINS-28718 are mutually exclusive, unless you're referring to automatically installing tools (which I think is a fun feature but I would immediately disable it in any production environment).

          I view a generic require step as a useful way to allow a script to safely declare runtime dependencies and nothing more. Every scripting environment, even JavaScript these days, has a similar syntax.

          R. Tyler Croy added a comment - jglick I don't see how my proposal and JENKINS-28718 are mutually exclusive, unless you're referring to automatically installing tools (which I think is a fun feature but I would immediately disable it in any production environment). I view a generic require step as a useful way to allow a script to safely declare runtime dependencies and nothing more. Every scripting environment, even JavaScript these days, has a similar syntax.

          Andrew Bayer added a comment -

          I'm +1 overall - tools will need a fair amount of work to support a real version concept, but I'm actually beginning to kick around ideas for that anyway.

          Andrew Bayer added a comment - I'm +1 overall - tools will need a fair amount of work to support a real version concept, but I'm actually beginning to kick around ideas for that anyway.

          Andrew Bayer added a comment -

          Also, this would be handy, particularly with regards to tools, with Plumber - I was planning to put in some try/catch logic once tool management actually becomes a thing (which itself still depends on a consistent way to do version discovery), but if we can just use "require" that'd be smoother.

          Andrew Bayer added a comment - Also, this would be handy, particularly with regards to tools, with Plumber - I was planning to put in some try/catch logic once tool management actually becomes a thing (which itself still depends on a consistent way to do version discovery), but if we can just use "require" that'd be smoother.

          Jesse Glick added a comment -

          Again -1 on a general require. Particular things that might be needed are better handled with dedicated steps or system.

          Jesse Glick added a comment - Again -1 on a general require . Particular things that might be needed are better handled with dedicated steps or system.

          Liam Newman added a comment -

          So, we're disagreeing about whether to have a generic require or a plugin specific one?

          What about implementing the generic syntax, but with only plugin name for now?

          require plugin: 'junit-plugin' 
          

          Then we have the concept and can consider expanding it (or not) later?

          Liam Newman added a comment - So, we're disagreeing about whether to have a generic require or a plugin specific one? What about implementing the generic syntax, but with only plugin name for now? require plugin: 'junit-plugin' Then we have the concept and can consider expanding it (or not) later?

          Baptiste Mathus added a comment - Proposal in https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/31

          Just a quick status update as I've been unable to push this forward in the last few months: I'm leaving myself assigned so that this shows up on my JIRA board for now, because I hope to be able to get back to it some day.

          BUT, I'm posting this so that anyone feeling an itch to push this to completion just feel free to take over. Then either just reassign to you, or ping me privately for any question (related to taking over the development of this, I don't mean any usage question. Because then it'd be the users ML instead).

          Thank you!

          Baptiste Mathus added a comment - Just a quick status update as I've been unable to push this forward in the last few months: I'm leaving myself assigned so that this shows up on my JIRA board for now, because I hope to be able to get back to it some day. BUT, I'm posting this so that anyone feeling an itch to push this to completion just feel free to take over. Then either just reassign to you, or ping me privately for any question (related to taking over the development  of this, I don't mean any usage question. Because then it'd be the users ML instead). Thank you!

          Unassigned myself to clarify I'm not working on this currently.

          Baptiste Mathus added a comment - Unassigned myself to clarify I'm not working on this currently.

          While commenting on JENKINS-49651 I had an idea that could make this almost automatic:
          Extend plugin metadata with (RPM style) Provides for pipeline symbols (& extensions,... ) they implement. With that metadata available in the Update Center a build that tries to use say the junit step could instead of failing the build be paused and the user could be prompted if they want to install the plugin that provides that step of if they want to abort the build:

          • Pipeline execution detects unknown step / use of a global / unknown type referenced.
          • Pipeline execution paused (like with an input step?)
          • Query Update Center metadata if there are plugins that provide the missing references
          • Prompt the user to install those plugins or fail the build (possibly saving ignored dependencies)
          • User selects to install the missing plugins -> continue the pipeline execution
          • maximum user satisfaction

          Ing. Christoph Obexer added a comment - While commenting on JENKINS-49651 I had an idea that could make this almost automatic: Extend plugin metadata with (RPM style) Provides for pipeline symbols (& extensions,... ) they implement. With that metadata available in the Update Center a build that tries to use say the junit step could instead of failing the build be paused and the user could be prompted if they want to install the plugin that provides that step of if they want to abort the build: Pipeline execution detects unknown step / use of a global / unknown type referenced. Pipeline execution paused (like with an input step?) Query Update Center metadata if there are plugins that provide the missing references Prompt the user to install those plugins or fail the build (possibly saving ignored dependencies) User selects to install the missing plugins -> continue the pipeline execution maximum user satisfaction

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            6 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: