Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jobs with only default parameters don't build #316

Open
Musi13 opened this issue Jul 17, 2020 · 3 comments
Open

Jobs with only default parameters don't build #316

Musi13 opened this issue Jul 17, 2020 · 3 comments
Labels

Comments

@Musi13
Copy link

Musi13 commented Jul 17, 2020

Note: Filing this under bug because its unexpected behavior, but this could also be considered an enhancement

Version Info

  • Parameterized Builds for Jenkins: 4.0.10
  • Bitbucket Server: 6.9.1
  • Jenkins: 2.206

How to reproduce

  1. Create a job in Jenkins with at least one parameter and give it a default value
  2. Create a job entry in 'ParameterizedBuilds' config to build that Jenkins job and give it NO parameters
  3. Trigger the build -> receive 400 Bad Request

Some detail:
There's two endpoints that Jenkins uses to trigger jobs, .../build and .../buildWithParameters. When not provided any parameters, the ParameterizedBuilds plugin posts to .../build (since it assumes the job takes no parameters). If a job has any parameters, even if they have defaults, this returns 400. For those jobs, we should post to .../buildWithParameters with no params specified. Unfortunately, posting to .../buildWithParameters when a job takes no parameters causes a 500.

I think a good solution to this would be some way to specify that a job takes parameters, even if we don't have any we want to send (i.e. change this argument to setUrlPath).

Nginx logs for what I'm talking about:

# Current behavior
"POST /job/verify.bugspray.multi/job/trigger-test/build HTTP/1.1" 400 524 "-" "Java/1.8.0_172" "-"

# Manually specify the missing parameter, user has to click through the confirmation form
"POST /job/verify.bugspray.multi/job/trigger-test/buildWithParameters?DEBUG_TIME=0 HTTP/1.1" 201 5 "-" "Java/1.8.0_172" "-"

# Made an empty parameter (just whitespace in Build Parameters box), still has popup but works
"POST /job/verify.bugspray.multi/job/trigger-test/buildWithParameters?+= HTTP/1.1" 201 5 "-" "Java/1.8.0_172" "-"

# Manual verification that buildWithParameters without params works
"POST /job/verify.bugspray.multi/job/trigger-test/buildWithParameters HTTP/1.1" 201 5 "-" "curl/7.64.1" "-"

# Manually showing triggering a no-parameter job with buildWithParameters doesn't work
"POST /job/verify.bugspray.multi/job/master/buildWithParameters HTTP/1.1" 500 18133 "-" "curl/7.64.1" "-"

I'm not really blocked here; I'll just have users click through the form and accept the default parameters, but this seems like unexpected behavior

Expected Behavior

Builds with all default parameters trigger successfully. Ideally, I'd like to click the 'Build in Jenkins' button and have the build start without showing a form, the same as a job that takes no parameters.

Current Behavior

Build fails with 'Bad Request' notification

@Musi13 Musi13 added the bug label Jul 17, 2020
@zehome
Copy link

zehome commented Aug 6, 2020

I think this has to do with jenkins, rather than parametrized-builds. If you use jenkins with multibranch Pipeline, jenkins can't do the first build with parameters specified. Don't know if that's your use case or not.

@Musi13
Copy link
Author

Musi13 commented Aug 10, 2020

I know about that quirk, but this is a bit different. Even with regular (non-pipeline) jobs where the parameters are defined, this behavior can be reproduced

@a-hacker
Copy link
Member

a-hacker commented Sep 6, 2020

I see what you mean @Musi13. I started looking into this but it seems like the only options are to either

  1. Get the job configuration and parse the xml or json for a parameters section. The issue here is that parameters seem to be defined in two different places and it isn't clear if those locations are the only locations especially for pipelines or multibranch pipelines. I also haven't checked if this would require different permissions from builds but I would assume so.
  2. Just try one endpoint and if it fails, try the other. This could work but I'm a little hesitant to implement this. It feels clunky and that code already is a bit messy to begin with.

A workaround for now is that you can add a parameter to Bitbucket hook settings that doesn't actually exist on the job. That will make the addon assume that the job is parameterized and when a build is triggered, Jenkins will just ignore the bad parameter. It may not be ideal but it should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants