Details
-
Type:
New Feature
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: pipeline-model-definition-plugin
-
Labels:
-
Similar Issues:
Description
By default a branch project will automatically run the first build, with no parameters, so params will just pick up any default values. You have the option to suppress the automatic first build, but this does not give you any way to enter parameters for it (at least in the UI; perhaps possible via CLI/REST), since Jenkins does not know what the parameters are going to be until it starts running. But in the case of Declarative we could in principle inspect the Jenkinsfile when the branch project is created (via SCMFileSystem) and determine the parameter definitions by static parsing without actually running.
More generally, if Declarative is in use and there are properties, we could set all the project properties when the branch project is created, even if the first build is run automatically. (Though I would suggest that the automatic first build should be automatically suppressed if there is a ParametersDefinitionProperty.)
Attachments
Issue Links
- duplicates
-
JENKINS-50365 Reload pipeline script without executing the job
-
- Reopened
-
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
-
JENKINS-45454 Pipeline from SCM jobs should have a fetch option
-
- Resolved
-
- is related to
-
-
- Open
-
- relates to
-
-
- Open
-
-
-
- Open
-
- links to
Activity
Tim Black I am trying your solution but I am facing an issue, env.BRANCH_NAME is null according to this: https://www.tikalk.com/posts/2017/05/21/how-to-evaluate-git-branch-name-in-a-jenkins-pipeline-using-gitscm/#:~:text=One%20of%20Jenkins%20environment%20variable%20is%20called%20BRANCH_NAME,you%20print%20it%2C%20the%20returned%20value%20is%20%E2%80%98null%E2%80%99. that behavior happens sometimes in pipeline jobs.
I understand you just want to rerun the job, so I use env.JOB_NAME and the job is rerun successfully but I am again not prompted to enter parameters. (the behavior we face in 'build now' rather than 'build with parameters')
Could you please help?
menna khaled
added a comment - Tim Black I am trying your solution but I am facing an issue, env.BRANCH_NAME is null according to this: https://www.tikalk.com/posts/2017/05/21/how-to-evaluate-git-branch-name-in-a-jenkins-pipeline-using-gitscm/#:~:text=One%20of%20Jenkins%20environment%20variable%20is%20called%20BRANCH_NAME,you%20print%20it%2C%20the%20returned%20value%20is%20%E2%80%98null%E2%80%99. that behavior happens sometimes in pipeline jobs.
I understand you just want to rerun the job, so I use env.JOB_NAME and the job is rerun successfully but I am again not prompted to enter parameters. (the behavior we face in 'build now' rather than 'build with parameters')
Could you please help? menna khaled if your pipeline does not have `BRANCH_NAME` available, that feels like a problem with your Jenkins/plugin installation/versioning, and I cannot help you with that. I will say however that `BRANCH_NAME` in my example is only used to construct the name of the job to (re-)build using [the build step](https://www.jenkins.io/doc/pipeline/steps/pipeline-build-step/#build-build-a-job), so YMMV:
It might sound a bit unorthodox, but really, isn't there a way to solve this properly (from the point of view of Jenkins users), without messy and inconvenient workarounds?
For example, if a pipeline is saved (on the UI or with CLI or ...), it might be parsed automagically and look for parameters only and do the same with them as if the job was run? Or actually run the job on save but somehow limited to parameter properties only (and hide the run from the history)? Or...
I'm sure it is not very simple to implement but it is quite a Major issue...
balee balee
added a comment - It might sound a bit unorthodox, but really, isn't there a way to solve this properly (from the point of view of Jenkins users), without messy and inconvenient workarounds?
For example, if a pipeline is saved (on the UI or with CLI or ...), it might be parsed automagically and look for parameters only and do the same with them as if the job was run? Or actually run the job on save but somehow limited to parameter properties only (and hide the run from the history)? Or...
I'm sure it is not very simple to implement but it is quite a Major issue... it might be parsed automagically and look for parameters only
That is exactly what this issue proposes (for Declarative Pipeline).
Brandon Squizzato that's the same thing we did too, though our parameter is "loadParamsAndAbort"