Would the aspect that "parameters are in Jenkinsfile, but don't get used when I run the project" make this considered a bug?

How is this fixed? I do not see a link to a closed issue that addresses the problem.

I also wonder how this is fixed?

I am also interested in how this was resolved.

it will be great to have this feature instead of rebuld the job in order to get the latest Params from the pipeline script

This is a major problem, a hole, in the pipeline feature. The workaround is lame: run the pipeline after modifying the jenkinsfile (in source control); kill the job as soon as Jenkins has processed the updated jenkinsfile which seems to happen right after it pulls the code at the start of the job; then run again.

I realize that this is not trivial to fix. Jenkins needs to load the jenkinsfile from source control; so it has to know exactly where to find it. For example, I usually set the git branch to a parameter so that you can choose the branch at job start time. So, to run a job, Jenkins would need to know the branch, load the jenkinsfile, then present the parameters from that file. That's alot to ask for ... since the branch may be parameter driven ... circularity.

For this, Jenkins would need to treat branch as a special parameter - not a custom parameter. 

Note that azure devops does not have this problem. It loads the pipeline configuration file after you select a source branch.

A complication is that although I'm using and talking about git, there are other source control systems. So, a general purpose solution would require changes for each source control system.

Could consider a different feature that is much easier to implement, is not a good as what I describe above, but is much better than current functionality. Add a way (button) to reload the jenkinsfile params. Would need to present the existing params since one may include the branch name. Could add the button on the start job view. In addition to the (poorly named) "Build" button, add a button named like "reload jenkinsfile". It would load the jenkinsfile from source control and update the cached parameter config. The user would remain on the build start view with updated parameters.

This has been a great annoyance to us for a while now.

We've worked around this by adding a checkbox parameter to most of our build jobs which, if checked, triggers all dependent jobs and then fails. That ensures that our pipeline and all dependent build jobs are up to date.

We don't do it very often, but anytime we do rename a parameter for a build we go through weeks and weeks of failed builds, because we need to support different versions of our software and build parameters will differ between branches.

Even with the workaround I described above, it takes between 10 and 15 minutes to trigger and reload dependent jobs. It is a very annoying time tax.

From what I've read, I realize that this seems to be a very complicated requirement, but I would be soooooooooooo happy to see it realized.

Otherwise, I'm very happy with Jenkins. Keep up the good work.

Quick update: the latest "reload" took 33 minutes.