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 created issue -
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-31582 [ JENKINS-31582 ]

          R. Tyler Croy added a comment -

          I've been thinking a lot about this general idea the past couple weeks, and had even considered writing a plugin last weekend before I got sick

          I think a more generic "require" syntax would be ideal for example:

          require 'junit' /* plugin artifactId */
          require 'parallel-text-executor'
          

          Which could be expanded upon with the keyword arguments in groovy to support additional requirement statements in the future, e.g.

          /* Naturally all of these could be squished into one require statement */
          require plugin: 'junit'
          require core: '1.642.4'
          require tool: ['Maven' : '3.3.3']
          

          I'm curious what hrmpw and abayer think of this syntax.

          The simplest approach would simply be a step which fails if some of the requested plugins are missing or too old:

          Mostly agreed, i suggest that the pipeline should abort because of missing dependencies with console outputs stating this Jenkins instance is lacking the required dependencies to execute this pipeline. I generally interpret failures to mean the Pipeline is broken (user error) rather than something requiring a user/administrator cooperation to rectify. I don't have much better reasoning than that, but an abort would catch my gaze a lot sooner than a failure, unfortunately

          As far as version restricting goes, in my mind I was thinking on punting on that for now until some more users using any require syntax.

          R. Tyler Croy added a comment - I've been thinking a lot about this general idea the past couple weeks, and had even considered writing a plugin last weekend before I got sick I think a more generic "require" syntax would be ideal for example: require 'junit' /* plugin artifactId */ require 'parallel-text-executor' Which could be expanded upon with the keyword arguments in groovy to support additional requirement statements in the future, e.g. /* Naturally all of these could be squished into one require statement */ require plugin: 'junit' require core: '1.642.4' require tool: [ 'Maven' : '3.3.3' ] I'm curious what hrmpw and abayer think of this syntax. The simplest approach would simply be a step which fails if some of the requested plugins are missing or too old: Mostly agreed, i suggest that the pipeline should abort because of missing dependencies with console outputs stating this Jenkins instance is lacking the required dependencies to execute this pipeline. I generally interpret failures to mean the Pipeline is broken (user error) rather than something requiring a user/administrator cooperation to rectify. I don't have much better reasoning than that, but an abort would catch my gaze a lot sooner than a failure, unfortunately As far as version restricting goes, in my mind I was thinking on punting on that for now until some more users using any require syntax.

          Patrick Wolf added a comment -

          Based on your example above I don't know if you intended that you could specify a version for plugins like you did for Tools

          require 'junit'  /* simply checks for any version */
          

          or

          require ['junit' : '1.11']  /* checks for that version */
          

          or

          require ['junit' : '>1.11'] /* 1.11 or above */
          

          This might be too much like gemspec notation it would be clear what is needed.

          Patrick Wolf added a comment - Based on your example above I don't know if you intended that you could specify a version for plugins like you did for Tools require 'junit' /* simply checks for any version */ or require [ 'junit' : '1.11' ] /* checks for that version */ or require [ 'junit' : '>1.11' ] /* 1.11 or above */ This might be too much like gemspec notation it would be clear what is needed.

          R. Tyler Croy added a comment -

          hrmpw with tools, there is no "version range" in the Tool installers right now, so in my head it was a fairly direct mapping selecting a version from a dropdown in a Freestyle job configuration page. If we were to support "just use Maven, any maven" i think that would be venturing too far from what Jenkins currently does.

          The reason for avoiding the version ranges right now, in my opinion, is that I'm not confident the right thing that would meet users' needs would be specifying a singular version (could be too restrictive), specify a base version (could be too relaxed) and don't want to introduce the full maven version range syntax into this

          R. Tyler Croy added a comment - hrmpw with tools, there is no "version range" in the Tool installers right now, so in my head it was a fairly direct mapping selecting a version from a dropdown in a Freestyle job configuration page. If we were to support "just use Maven, any maven" i think that would be venturing too far from what Jenkins currently does. The reason for avoiding the version ranges right now, in my opinion, is that I'm not confident the right thing that would meet users' needs would be specifying a singular version (could be too restrictive), specify a base version (could be too relaxed) and don't want to introduce the full maven version range syntax into this

          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.

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

              Created:
              Updated: