Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Wiki Markup
{jenkins-plugin-info:pluginId=parameter-defaults-options-plugin}

Excerpt

Parameterize builds without requiring a user to submit a form when built manually.  Use different default values depending on whether the build was manual or triggered.

Why do we need this plugin?

Use Case: Parameterizing a long list of email addresses 2 places in a job

In our maven jobs, we configure the email parameter to be passed to a maven goal through "-Demail.to.addresses=${email.to.addresses}" and we also want to use that email address in the email configuration post-goals.  So, it would seem obvious that using parameterization would be the right way to go.  Except now the job required the user to submit an extra form every time a job is manually built.  Why do we care?  For one reason, it's slightly annoying, and that's bad.  But, the real reason is that we get accustomed to running jobs manually and as soon as we click the build button we turn our attention to something else, and forget that for some jobs we need to submit an additional form.  Many times I find myself checking back to see if a job has completed, and aaarg - I forgot to submit the parameters form.

Use Case: Optional profiles in Maven jobs

We have some profiles that make the builds take a lot longer.  Those profiles need to be run nightly, but during the day, they're optional.  So, we make our Maven top level targets look like "clean install ${optionalProfiles}" and then we add a build parameter with a default value of "-Dmyprofile".  Then, if the job is run manually, the user clicks on that text field, and blanks it out, and then submits the form.  The profile doesn't get activated, but this is a pretty annoying work flow.

How does this plugin solve the problem?

By adding a new parameter type - "String Parameter (with defaults options)" (screenshot below isn't quite right, but it's close)

What is the plan to get this code working in Hudson?

Looking over the core code, the only reasonable way I could see to make this work is to make some backwards-compatible changes to ParametersDefinitionProperty and ParameterDefinition.  These changes allow ParametersDefinitionProperty to skip rendering the form page if all parameters are flagged as "never prompt".  It also allows ParametersDefinitionProperty to use a different default value than when a build was triggered.

This code has been written and tested, and a JIRA ticket and patch will soon be submitted.  After that patch is applied, this plugin can go live.  Until then, it can't be released.