Improve interface for specifying job's params

[Drugoy]

Currently the parameters for parameterized jobs need to be specified in VSCode's settings. That's not really handy. It would be way more comfortable to use this add-on if I could specify params somehow easier. I don't know how much VSCode is extensible, but it would be nice to have params specified right in the Jenkinsfile (say, in top comments section, a la PHPStorm) or as an extra tab in the ctrl+` pane.

[dave-hagedorn]

Hi there - thanks for the feedback.

Can you explain your workflow? I'm trying to understand how someone would use this feature.

When I'm writing a Jenkinsfile, I'm changing the job's code much more often than the its params - so I need to frequently re-run/debug a script with the same params. The current implementation works well (for me) in this regard. I can also add multiple job configs if I need to repeatedly re-test different sets of parameters against the same job.

Are you frequently changing the job's params as part of your development?

Discussing your suggestions:

• variables in top comments section - can you give an example of this? Since you're editing the Jenkinsfile comments to change the params, I'm curious why you wouldn't just change the param's default value directly in the Jenkinsfile: string(name: 'Greeting', defaultValue: 'Hello', description: 'How should I greet the world?')
• the ctrl+` pane isn't extensible AFAIK, so I don't think anything can be done there.

One option would be to write a webview, but that would show up as a new editor pane - so the UX flow would be a little weird, but not terrible

Another option would be allow a special value [prompt] (or similar) for a value's param in settings. If set, the param's value would come from a prompt at launch time. This would however would prompt sequentially for each param, since VSCode does not allow prompting for multiple values at once.

Thoughts?

[Drugoy]

While I develop a building script - I do not know beforehand what options will the script have. Maybe, the correct way to use your plugin is to avoid parameters at all and then it's not a huge problem, because while I develop - I may use def myparam = value instead. That'd generally work, I'd just have to do a finalizing move - convert those defs into proper params manually and make the last test manually as well.

As for variables in top comments section - I meant stuff like that:

/**
 * NavigatorUser
 * @property integer $municipality_id
 * @property integer $partner_id

 * @method  NavigatorUser scopeByMunicipality($id)
 * @property Municipality $municipality
 * @method NavigatorUser scopeByPartner($id)
 * @method NavigatorUser scopeByRegion($id)
 */

This is an example of how it is done in PHPStorm in PHP, it tells the IDE which methods to expect and which properties should the object of this class have. I meant something similar.

I'm not sure what you meant by string(name: 'Greeting', defaultValue: 'Hello', description: 'How should I greet the world?') - surely I'd need to go to your plugin's settings to set those params as well? Well, the whole idea is to avoid going into settings, because it can't be opened fast. The same way, using [prompt] wouldn't help too, if it should be specified in the plugin's settings.

[peterloron]

We have jobs where the parameters are defined in the pipeline like the code below. When I try to run a job like that from VSCode, I get an error: "HTTP ERROR 400 Nothing is submitted"

properties( [ buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '10', numToKeepStr: '20')), disableConcurrentBuilds(), disableResume(), durabilityHint('PERFORMANCE_OPTIMIZED'), [$class: 'RebuildSettings', autoRebuild: false, rebuildDisabled: false], parameters([ string(name: 'LOCALES', defaultValue: "en_us, fr_fr"), string(name: 'QUERY_SETS', defaultValue: "London"), booleanParam(name: 'PRE_THRESHOLD', defaultValue: true), ]) ] )