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

Exclude Choice Parameter Choices from Child Jobs

    XMLWordPrintable

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not A Defect
    • ez-templates-plugin
    • None
    • Jenkins ver. 2.67
      ez-templates-1.3.0

    Description

      Hi drekbour, We just upgraded ez-template plugin in production and unfortunately had to revert back again. JENKINS-38755 does not fix the need to have choices in the choice parameters that are completely different from the template. 

      For Example:

       

        Template Child Result Comment
      1 ABC DG DG Child values override template
      2 JKL CD CD Child values override template

      This is needed as we have some jobs that have choices different from the template and needs to be different...

      Attachments

        Activity

          I also forgot to note that ticking the "Retain local job parameter values" does not work with choice parameters as I expected it to.

           

          emoshaya_cognitoiq Ebrahim Moshaya added a comment - I also forgot to note that ticking the "Retain local job parameter values" does not work with choice parameters as I expected it to.  
          drekbour Marc Carter added a comment - - edited

          Combination of existing rules means you are probably seeing 1 ABCDG 2 JKLCD because a child cannot delete choices provided by it's template (similarly it cannot delete JobParamters provided by the template).

          Is your last comment related to something other than this?

          What is really happening is that EZ should not support anything other changing the default choice (rule 2). Changing the nature of these choices (especially wholesale as in your example) is pushing the boundary of saying this is a templating scenario (ie. are these really one choice parameter?).

          If it's not sensitive I'd like to know roughly what A,B,C,D and G are. To understand if there is a different way to achieve your goal.

          drekbour Marc Carter added a comment - - edited Combination of existing rules means you are probably seeing 1 ABCDG 2 JKLCD because a child cannot delete choices provided by it's template (similarly it cannot delete JobParamters provided by the template). Is your last comment related to something other than this? What is really happening is that EZ should not support anything other changing the default choice (rule 2). Changing the nature of these choices (especially wholesale as in your example) is pushing the boundary of saying this is a templating scenario (ie. are these really one choice parameter?). If it's not sensitive I'd like to know roughly what A,B,C,D and G are. To understand if there is a different way to achieve your goal.

          Hi drekbour,

           

          we have deploy jobs with the choice parameter set to Environments. we have child jobs with the environments set to non production environments that are only accessible by developers. e.g. dev, test, uat

           

          Then, we also have child jobs set to production environments that are only accessible by release managers. e.g. pre-prod, prod.

           

          Both job types inherit from same template.

           

          The template itself has the Environments parameter set to nothing as default.

           

           

           

          emoshaya_cognitoiq Ebrahim Moshaya added a comment - Hi drekbour ,   we have deploy jobs with the choice parameter set to Environments. we have child jobs with the environments set to non production environments that are only accessible by developers. e.g. dev, test, uat   Then, we also have child jobs set to production environments that are only accessible by release managers. e.g. pre-prod, prod.   Both job types inherit from same template.   The template itself has the Environments parameter set to nothing as default.      
          drekbour Marc Carter added a comment - - edited

          But your documented solution (template has zero choices, children add their own choices) works just fine with ez-templates and makes some real-world sense.

          The original request ...

          1 ABC DG DG Child values override template

          ... doesn't make sense in relation to your scenario. What would ABC be that you want to completely delete them?

          Perhaps what you intend is defaults for developer / manager classes of job. EZ partially supports nested templates so you can have template, template-manager, template-developer. Currently saves to the "template" grandparent don't cascade all the way down without resaving template-managers (JENKINS-45741).

          drekbour Marc Carter added a comment - - edited But your documented solution (template has zero choices, children add their own choices) works just fine with ez-templates and makes some real-world sense. The original request ... 1 ABC DG DG Child values override template ... doesn't make sense in relation to your scenario. What would ABC be that you want to completely delete them? Perhaps what you intend is defaults for developer / manager classes of job. EZ partially supports nested templates so you can have template, template-manager, template-developer. Currently saves to the "template" grandparent don't cascade all the way down without resaving template-managers ( JENKINS-45741 ).
          drekbour Marc Carter added a comment -

          Hi, do you have a response?

          drekbour Marc Carter added a comment - Hi, do you have a response?

          drekbour so sorry for the late response! I see the choice parameter as a parameter with name and value the exact same as String or Text Parameters... I may have a string parameter with name TEST_NAME and the value will be different in every single child job inheriting the template... In fact, I may just want the default value in the template to have a blank value...The choice parameter should be treated the exact same way.. i.e. Parameter Name and the choices are the values which could be different in every single child job but with the same parameter name. The "retain local job parameter values" setting in the template should do just that and allow me to have my own choices in the child jobs... 

           

          Imagine a scenario where I have a template to automate the ordering of food from various Takeaways:

           

          Template Name:       OrderFood-Template

          Parameters:           Choice Parameter: Name: MENU

                                                                        Choice Values: blank

           

          Inheriting child jobs:

           

          McDonalds:          Choice Parameter: Name: MENU

                                                                       Choice Values: McDonalds menu choices

           

          Burger King:          Choice Parameter: Name: MENU

                                                                       Choice Values: Burger King menu choices

           

          KFC:          Choice Parameter: Name: MENU

                                                                       Choice Values: KFC menu choices

           

          The above is just another example scenario... My scenario is that we have a generic deployment job with an ENVIRONMENT choice parameter... the choice parameter has different choices based on the type of deployment..

          emoshaya_cognitoiq Ebrahim Moshaya added a comment - drekbour so sorry for the late response! I see the choice parameter as a parameter with name and value the exact same as String or Text Parameters... I may have a string parameter with name TEST_NAME and the value will be different in every single child job inheriting the template... In fact, I may just want the default value in the template to have a blank value...The choice parameter should be treated the exact same way.. i.e. Parameter Name and the choices are the values which could be different in every single child job but with the same parameter name. The "retain local job parameter values" setting in the template should do just that and allow me to have my own choices in the child jobs...    Imagine a scenario where I have a template to automate the ordering of food from various Takeaways:   Template Name:       OrderFood-Template Parameters:           Choice Parameter: Name: MENU                                                               Choice Values: blank   Inheriting child jobs:   McDonalds:          Choice Parameter: Name: MENU                                                              Choice Values: McDonalds menu choices   Burger King:          Choice Parameter: Name: MENU                                                              Choice Values: Burger King menu choices   KFC:          Choice Parameter: Name: MENU                                                              Choice Values: KFC menu choices   The above is just another example scenario... My scenario is that we have a generic deployment job with an ENVIRONMENT choice parameter... the choice parameter has different choices based on the type of deployment..
          drekbour Marc Carter added a comment -

          Closing as EZ never will be able to sync removal of choices. What does work much more smoothly now is cascading save so it's quite possible to have a hierarchy of templates which incrementally add the constrained list of choies available to child jobs:

          {template : env = []}
            --> {non-prod-template : env = [dev,uat]}
              --> {my-job : env = [dev,uat]}
            --> {prod-template : env = [pre,prod]}
              --> {my-job2 : env = [pre,prod]}

          This has the same effect

          drekbour Marc Carter added a comment - Closing as EZ never will be able to sync  removal of choices. What does work much more smoothly now is cascading save so it's quite possible to have a hierarchy of templates which incrementally add the constrained list of choies available to child jobs: {template : env = []} --> {non-prod-template : env = [dev,uat]} --> {my-job : env = [dev,uat]} --> {prod-template : env = [pre,prod]} --> {my-job2 : env = [pre,prod]} This has the same effect

          People

            drekbour Marc Carter
            emoshaya_cognitoiq Ebrahim Moshaya
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: