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

pipeline steps from a jenkins plugin do not show any default values in the form

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean - Candidates

      Description

      I've created a jenkins plugin with a bunch of pipeline steps for use in either scripted or declarative pipelines. They show up in the regular Pipeline Syntax UI in Jenkins along with the Blue Ocean Pipeline editor.

      In the Pipeline Syntax UI the default values appear in the form (due to the `default="foo"` in the jelly config.xml files) however in the Blue Ocean pipeline editor the forms are always blank.

      Is this a known bug with Blue Ocean pipeline editor; or is there some alternative way to specify default values for the form in the plugin so that the pipeline editor can find them?

       

      If you want to try out the plugin yourself there's a snapshot plugin here:

      https://github.com/fabric8-jenkins/fabric8-declarative-pipeline-step-functions-plugin#building

        Attachments

          Activity

          Hide
          michaelneale Michael Neale added a comment -

          Cliff Meyers I totally did not fully read the description of the ticket. Basically at the moment the steps put it in the jelly for classic UI, so I don't think the "data" that is locked up in them will be available for the pipeline editor in blue ocean. 

           

          So this changes the nature of the ticket, basically we need to find a way to include the default values in the code, vs the UI, and surface that via the API. this is a VERY different problem, worth thinking about, but may be more effort, as it then required the plugins that provide the steps to be modified to include the default values vs Jelly. 

           

          Is this a tractable problem? it now seems much bigger than it was when we started... (and I don't think we can programmatically reliably dig things out of jelly...)

          Show
          michaelneale Michael Neale added a comment - Cliff Meyers I totally did not fully read the description of the ticket. Basically at the moment the steps put it in the jelly for classic UI, so I don't think the "data" that is locked up in them will be available for the pipeline editor in blue ocean.    So this changes the nature of the ticket, basically we need to find a way to include the default values in the code, vs the UI, and surface that via the API. this is a VERY different problem, worth thinking about, but may be more effort, as it then required the plugins that provide the steps to be modified to include the default values vs Jelly.    Is this a tractable problem? it now seems much bigger than it was when we started... (and I don't think we can programmatically reliably dig things out of jelly...)
          Hide
          jstrachan James Strachan added a comment -

          I did wonder if the Blue Ocean editor was not using Jelly - which is fine - I guess we just need to figure out some way that a Step can expose more metadata about itself (e.g. display names, default values, possibly validation/editor CSS styles like number/positive/required and the like).

          This could be a Java API or static metadata (xml / json / yaml / something else) as for now the default values are not dynamic; though I guess a Java API of sorts might be cleaner longer term for more complex processing of defaults. (e.g. if one property is a github organisation name, then the combo box of repository names may be dynamic etc) 

          Show
          jstrachan James Strachan added a comment - I did wonder if the Blue Ocean editor was not using Jelly - which is fine - I guess we just need to figure out some way that a Step can expose more metadata about itself (e.g. display names, default values, possibly validation/editor CSS styles like number/positive/required and the like). This could be a Java API or static metadata (xml / json / yaml / something else) as for now the default values are not dynamic; though I guess a Java API of sorts might be cleaner longer term for more complex processing of defaults. (e.g. if one property is a github organisation name, then the combo box of repository names may be dynamic etc) 
          Hide
          jstrachan James Strachan added a comment -

          Cliff Meyers sorry those steps are confusing  it was an experiment to create a simple POJO model for writing steps such that developers don't need to grok any of the ninja jenkins stuff around groovy / CPS / Steps et al.

          What actually happens is a maven plugin generates the Step class. Here's the generated step class for the mavenPipeline step: https://gist.github.com/jstrachan/96b116ce233249e9bea8dbce93343b24

          so its regular Step stuff - so we can hack that code to do whatever you need. Is there an example anywhere of a Step written to provide more metadata for Blue Ocean editor that I can copy/noodle? 

          Show
          jstrachan James Strachan added a comment - Cliff Meyers sorry those steps are confusing  it was an experiment to create a simple POJO model  for writing steps such that developers don't need to grok any of the ninja jenkins stuff around groovy / CPS / Steps et al. What actually happens is a maven plugin generates the Step class. Here's the generated step class for the mavenPipeline step: https://gist.github.com/jstrachan/96b116ce233249e9bea8dbce93343b24 so its regular Step stuff - so we can hack that code to do whatever you need. Is there an example anywhere of a Step written to provide more metadata for Blue Ocean editor that I can copy/noodle? 
          Hide
          michaelneale Michael Neale added a comment -

          James Strachan Cliff Meyers I am not sure we can solve this within the original scope here... basically we need to find a way to expose this meta data, and then all the steps need to be updated to have the defaults in their classes (vs in jelly, no small job) 

           

          James Strachan were there specific steps you were thinking of where this is most problematic, or were you looking at making new steps, or libraries that could do with defaults? 

           

           

          Show
          michaelneale Michael Neale added a comment - James Strachan Cliff Meyers I am not sure we can solve this within the original scope here... basically we need to find a way to expose this meta data, and then all the steps need to be updated to have the defaults in their classes (vs in jelly, no small job)    James Strachan were there specific steps you were thinking of where this is most problematic, or were you looking at making new steps, or libraries that could do with defaults?     
          Hide
          jstrachan James Strachan added a comment - - edited

          After hitting a limitation in the simple POJO model (java steps can't easily invoke other steps like sh()) I'm now focussing on a single 'pseudo step' , mavenFlow defined via groovy: https://github.com/fabric8-jenkins/fabric8-pipelines-plugin/blob/master/src/main/resources/dsl/mavenFlow.groovy

          then exposed using a GlobalVariable: https://github.com/fabric8-jenkins/fabric8-pipelines-plugin/blob/master/src/main/java/org/jenkinsci/plugins/fabric8/dsl/MavenFlowDSL.java#L26

          so maybe that @Extension class could be the pseudo step we use to try expose metadata into. Though now things are slightly different in right now this pseudo step doesn't even appear in blue ocean at all  as its not a Step per say but a global variable.

          So I wonder if we need to raise a separate issue? We've kinda 2 issues now:

          • how to add extra metadata to DescribableModel for things like displayName, defaultValue, required, number & other validation/CSS type stuff
          • how to expose a DescribableModel at all for 'groovy steps' which are not Java Step classes but DSL functions exposed as global variables like example https://github.com/jenkinsci/simple-build-for-pipeline-plugin/

          I've just raised https://issues.jenkins-ci.org/browse/JENKINS-48205 for the latter; we should maybe try tackle that one first - then try figure out how to add more metadata/info to the DescribableModel for this issue?

          Show
          jstrachan James Strachan added a comment - - edited After hitting a limitation in the simple POJO model (java steps can't easily invoke other steps like sh()) I'm now focussing on a single 'pseudo step' , mavenFlow defined via groovy:  https://github.com/fabric8-jenkins/fabric8-pipelines-plugin/blob/master/src/main/resources/dsl/mavenFlow.groovy then exposed using a GlobalVariable: https://github.com/fabric8-jenkins/fabric8-pipelines-plugin/blob/master/src/main/java/org/jenkinsci/plugins/fabric8/dsl/MavenFlowDSL.java#L26 so maybe that @Extension class could be the pseudo step we use to try expose metadata into. Though now things are slightly different in right now this pseudo step doesn't even appear in blue ocean at all  as its not a Step per say but a global variable. So I wonder if we need to raise a separate issue? We've kinda 2 issues now: how to add extra metadata to DescribableModel for things like displayName, defaultValue, required, number & other validation/CSS type stuff how to expose a DescribableModel at all for 'groovy steps' which are not Java Step classes but DSL functions exposed as global variables like example  https://github.com/jenkinsci/simple-build-for-pipeline-plugin/ I've just raised https://issues.jenkins-ci.org/browse/JENKINS-48205  for the latter; we should maybe try tackle that one first - then try figure out how to add more metadata/info to the DescribableModel for this issue?

            People

            • Assignee:
              Unassigned
              Reporter:
              jstrachan James Strachan
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: