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

More options for default parameters

    Details

    • Type: New Feature
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      See description I put together a while ago on the wiki. I will also attach the code I wrote that works, but never got committed.

      https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options

        Attachments

          Activity

          Hide
          ntshako Hannes Kogler added a comment - - edited

          as I see it the the implementation described here: https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options?focusedCommentId=80183932&#comment-80183932
          would be much easier regarding usability than the workaround with the EnvInject Plugin, that has other intentions than just "hide" properties being setup individually for single jobs from the gui.

          So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case?

          Show
          ntshako Hannes Kogler added a comment - - edited as I see it the the implementation described here: https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options?focusedCommentId=80183932&#comment-80183932 would be much easier regarding usability than the workaround with the EnvInject Plugin, that has other intentions than just "hide" properties being setup individually for single jobs from the gui. So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case?
          Hide
          danielbeck Daniel Beck added a comment -

          So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case?

          This is a change requested for Jenkins core, not about a new plugin. The trend has long been to move functionality out of core into independently updatable plugins, so rejecting new feature requests that are very similar to established plugins' features is consistent with that.

          Of course I'm not the final arbiter on what goes in and what does not, so feel free to reopen this issue. But based on my experience, this will not make it in, as it is not actually a necessary feature (since it has adequate alternatives), and brings significant additional complexity with it.

          Show
          danielbeck Daniel Beck added a comment - So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case? This is a change requested for Jenkins core, not about a new plugin. The trend has long been to move functionality out of core into independently updatable plugins, so rejecting new feature requests that are very similar to established plugins' features is consistent with that. Of course I'm not the final arbiter on what goes in and what does not, so feel free to reopen this issue. But based on my experience, this will not make it in, as it is not actually a necessary feature (since it has adequate alternatives), and brings significant additional complexity with it.
          Hide
          ntshako Hannes Kogler added a comment -

          I have tried out the workaround with the EnvInjectPlugin and generally it works.
          (by just declaring the key/value paris in the "Properties Content" section, like shown here: )
          https://wiki.jenkins-ci.org/download/attachments/57999800/EnvInject_Path.png?version=1&modificationDate=1342694716000

          But I still have a big disadvantage using this workaround. Finally I am also using the Promoted Builds Plugin and unfortunately the build parameters, predefined with the EnvInjectPlugin, won't be read by the Job Promotion being executed.

          Sure I have the possibility to configure the EnvInjectPlugin with my needed properties also for every single promotion step, but after all I need to duplicate the property definitions here again and again... and thats exactly what I wanted to prevent by using the EnvInjectPlugin!
          Whereas the properties, defined with the Jenkins Core functionality, are indeed readable by the configured promotion executions out-of-the-box.

          Or do you know any workaround for this use case as well?

          Show
          ntshako Hannes Kogler added a comment - I have tried out the workaround with the EnvInjectPlugin and generally it works. (by just declaring the key/value paris in the "Properties Content" section, like shown here: ) https://wiki.jenkins-ci.org/download/attachments/57999800/EnvInject_Path.png?version=1&modificationDate=1342694716000 But I still have a big disadvantage using this workaround. Finally I am also using the Promoted Builds Plugin and unfortunately the build parameters, predefined with the EnvInjectPlugin, won't be read by the Job Promotion being executed. Sure I have the possibility to configure the EnvInjectPlugin with my needed properties also for every single promotion step, but after all I need to duplicate the property definitions here again and again... and thats exactly what I wanted to prevent by using the EnvInjectPlugin! Whereas the properties, defined with the Jenkins Core functionality, are indeed readable by the configured promotion executions out-of-the-box. Or do you know any workaround for this use case as well?
          Hide
          danielbeck Daniel Beck added a comment -

          Or do you know any workaround for this use case as well?

          No. IMO, Promoted Builds is beyond broken, so I haven't used it in years.

          Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work.

          Show
          danielbeck Daniel Beck added a comment - Or do you know any workaround for this use case as well? No. IMO, Promoted Builds is beyond broken, so I haven't used it in years. Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work.
          Hide
          ntshako Hannes Kogler added a comment - - edited

          Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work.

          If depends on how many people use and need it for the promoted builds plugin steps as well. And I can imagine that those are quite a lot! For all those people the "workaround" with the EnvInjectPlugin is just an enormous effort to configure this plugin for every promotion step, and makes it simply unusable.
          I think the proposal on this site https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options doesn't sound like a completely changed behavior of the parameter feature in Jenkins... so I'm really a bit confused, why there is no one releasing this one

          Show
          ntshako Hannes Kogler added a comment - - edited Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work. If depends on how many people use and need it for the promoted builds plugin steps as well. And I can imagine that those are quite a lot! For all those people the "workaround" with the EnvInjectPlugin is just an enormous effort to configure this plugin for every promotion step, and makes it simply unusable. I think the proposal on this site https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options doesn't sound like a completely changed behavior of the parameter feature in Jenkins... so I'm really a bit confused, why there is no one releasing this one

            People

            • Assignee:
              Unassigned
              Reporter:
              jacob_robertson Jacob Robertson
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: