Details
-
New Feature
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
None
Description
When job parameters are defined in the Jenkinsfile/script, Jenkins doesn't know what parameters are required until the job is run. You see the problem? to run the job you need the parameters. To know what parameters are required to run the job.
This is most visible with a new branch in multibranch jobs (there have been complaints).
In scope:
- Investigate if it is possible to know without executing what parameters will be required
- If possible, an api to return such parameters
This could span general pipeline script, or pipeline model.
Attachments
Issue Links
- duplicates
-
-
- Open
-
- relates to
-
JENKINS-40631 first build fails because of missing parameter
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link | JENKINS-36291 [ 172300 ] |
Also - the editor knows the parameters defined in the Jenkinsfile (even if the job isn't run) since it's parsing the Jenkinsfile. Not sure how we could get this to Blue Ocean for kicking off builds without also doing a Jenkinsfile parse there too...
So since https://github.com/jenkinsci/workflow-cps-plugin/pull/60 landed, there's a new global variable, params. If you do a properties call adding parameters (let's say we add one named foo) and then do params.foo afterwards in the same run, you'll get the default value for foo, assuming one was defined. It's still not possible to prompt the user for parameters before having the build run with properties, but at least you can prevent the build from breaking due to undefined parameters this way. Thoughts as to whether that's sufficient? Should we also add it to the env global variable?
| Description |
When job parameters are defined in the Jenkinsfile/script, Jenkins doesn't know what parameters are required until the job is run. You see the problem? to run the job you need the parameters. To know what parameters are required to run the job. In scope: * Investigate if it is possible to know without executing what parameters will be required * If possible, an api to return such parameters This could span general pipeline script, or pipeline model. |
When job parameters are defined in the Jenkinsfile/script, Jenkins doesn't know what parameters are required until the job is run. You see the problem? to run the job you need the parameters. To know what parameters are required to run the job. This is most visible with a new branch in multibranch jobs (there have been complaints). In scope: * Investigate if it is possible to know without executing what parameters will be required * If possible, an api to return such parameters This could span general pipeline script, or pipeline model. |
hrm ok.. this may have to sit in the backlog for a while.
So whilst PR#60 helps with error message, it is still a broken UX that pops up for the wrong things... so we may need to park this for some future work to make it work out ahead of time what the params are via some kind of evaluation... I don't think this is a problem specific to declarative, and perhaps declarative shouldn't solve it?
EDIT: I am prepared to park this and then let things come in as bug reports... more thought is needed ...
| Link |
This issue relates to |
abayer although the params really works well, I would still add them to env too - thats just what people are used to.
| Priority | Major [ 3 ] | Minor [ 4 ] |
abayer params.foo will give it's default value, how about type? Can we get type value without executing a run of the script?
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Sprint | post-release [ 181 ] |
| Rank | Ranked higher |
| Sprint | post-release [ 181 ] | 1.1 [ 251 ] |
This came up in discussion with a CB customer (for Script, but I was discussing that this was more viable to do in Declarative). Apart from schedule, what seems to be the blocker here?
| Rank | Ranked higher |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Sprint | Blue Ocean up next [ 251 ] |
| Rank | Ranked lower |
| Link | This issue duplicates JENKINS-41929 [ JENKINS-41929 ] |
| Resolution | Duplicate [ 3 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
Benjamin Goldberg
added a comment - This is marked as resolved, but by what? Is there an open PR somewhere we can look at? Would love to see this feature in our installation of Jenkins and wondering if its available in the latest release.
Benjamin Goldberg
added a comment - This is marked as resolved, but by what? Is there an open PR somewhere we can look at? Would love to see this feature in our installation of Jenkins and wondering if its available in the latest release. It's duplicated. See the linked tickets for where this is really tracked.
Benjamin Goldberg
added a comment - jamesdumay I clicked through a number of associated tickets (many of which are duplicated themselves) and I am unable to find the PR that resolves this issue. Any chance we could add the link here as well?
Benjamin Goldberg
added a comment - jamesdumay I clicked through a number of associated tickets (many of which are duplicated themselves) and I am unable to find the PR that resolves this issue. Any chance we could add the link here as well? benjigoldberg https://issues.jenkins-ci.org/browse/JENKINS-41929 is ticket. There is no PR I am aware of that fixes this. Pipeline being scripted by default (outside of `pipeline`) makes this impossible in a sense (ie need to execute it before you know what parameters are used). Declarative has a chance that this can be elided pre-flight.
| Status | Resolved [ 5 ] | Closed [ 6 ] |
So I'm only thinking in terms of Declarative for the moment, because, well, viability.
The first thing coming to mind is to have the logic that takes the parameters section check if each parameter is already defined on the job at that point (with the same type too), and if not, add an environment variable for the parameter name using the default value for the parameter. i.e., the first run still would not prompt for parameters, but it would act as if the default parameters had been specified.