Resolve parameters that are set in the request body or in custom head…

[holleymcfly]

Currently there is no possibility to pass all parameters and a request body to the client.

Use case:
I want to pass the value
D:/jenkins/${Tag}/workspace
in the request body.

There is no possibility to do that, because the parameters are not resolved.

This change will resolve all the parameters within the request body and within custom headers, too.

[arkantos1482]

This feature has been needed for a long time. Thanks for contributing

Update:
I Build the plugin with holleymcfly's proposed changes, but it didn't work.
The problem still exists and Environment Variables aren't replaced with their actual values except in the URL.

Update2:
Here this guy actually proposed the correct code, which I tested and it did work on body (not header though)
http://stackoverflow.com/questions/38200675/susbstitute-environment-variables-in-request-body-of-httprequest-plugin-of-jenki

update3:
Actually, the previous one also didn't work all right, it was just a one-time config, and after you run the project, the actual values replaces the variables in the config. So you can only use it just once, and after that you have to reconfigure again.

[holleymcfly]

Hm, that's strange. But thank's for the updates, I will have a look at it.

[holleymcfly]

Hi arkantos1482,
I've added a test case to the code that works fine. So I'm not sure what the problem ist. At least I think that the flag "pass build params to URL" has to be set to true.
Could you please have a look at it?

Thanks,
Holger

[holleymcfly]

Hi arkantos1482,

I've done one more change: Now I noticed the code part where parameters are resolved in the URL (this has been done already). For that, a resolver method of the jenkins core is used. Also, not the original URL is modified, but a new variable is created (maybe that's the reason why the original configuration has been overwritten in my first version).

I do it now exactly the same way for the request body (I removed the replacement for custom headers, and could re-do that if the change for the request body works.).

Could you please check if this version works fine?

Thanks,
Holger

[arkantos1482]

Hi Holger,
Thanks a lot for your contribution to make this plugin work fine.
But it is really a shame though jenkins has only have one http req/res plugin, which still doesn't support variable replacement in body and header . And I believe this plugin doesn't support multipart form-data content type,either which makes u unable to upload files.
So what would you call a continuous delivery process without those features.
I ended up implementing those features in gradle/groovy which is the building automation system for android projects and more.

[holleymcfly]

Hi again,
I agree with you - it's at least a bit strange that there are not more plugins / contributors for those requirements.

Does your comment mean that the changes work fine now? If so, how would be the process to get this as an updated version in my jenkins installation (in the plugins section of Jenkins). Sorry for the maybe stupid questions, but I'm new to Jenkins plugin development.

Thanks,
Holger

[arkantos1482]

Hi Holger,
I'm sorry, I didn't compile the newly commited changes, you have just kindly contributed to this plugin.
And I'm not sure if I understand your question correctly, but If you mean, how to compile and test your changes,
1- you compile, package, run tests etc ... by "mvn package" command
2- after it is finished.. you get the (sth.hpi) (in our case (http_request.hpi) size around 900kb) file in the root project folder
3- in jenkins, uninstall the main plugin... and upload yours (the .hpi file) (in plugin manager/advanced)

regards
Abbas

[holleymcfly]

Hi Abbas,
thanks for these information. I did as you said and it works fine now - the parameters are replaced when the server receives the request!

Unfortunately, the http calls in the job configuration are not shown any more, and I also can't select this function in the pre or post build steps. I don't think that's related to my changes, but related to the packaging or installation. That leads me to the question how these changes can now be merged to the trunk and provided as a regular update of this plugin?

Thanks,
Holger

[vaskrist]

Hi Holger,

I have done the following (trying to create a MCVE):

• built the latest version from your master
• installed it on my a Jenkins instance (2.15)
• used it in a Freestyle job as GET, POST both inside a conditional step and outside calling a local httpbin

It replaced the URL and body variables correctly, ❌ but the headers were untouched.

See the the job log in pastebin: http://pastebin.com/0zKENMXd
I have also posted the job XML so you can import it: http://pastebin.com/mciCep8y

As you can see in the XML I am using:

• envinject@1.92.1
• conditional-buildstep@1.3.5 (which uses run-condition@1.0)
• http_request@1.8.12-SNAPSHOT

Michael

[holleymcfly]

Hi Michael,

thanks for your effort and the update.
I've written a few comments ago that I will focus on the request body and won't regard the headers in a first step ("I removed the replacement for custom headers, and could re-do that if the change for the request body works.").

So now as it works, I will investigate the headers again and come back with a comment when I think it's done!

Best,
Holger

[holleymcfly]

Hello Michael,
I've just checked in the changes to also replace parameters in custom headers.
Would you mind to create a new version again?

Thanks,
Holger

[vaskrist]

Hi Holger,

I have just noticed your comment and pulled the changes and rebuilt.

✅ The headers are now replaced correctly (in addition to all the other replacements working fine).

Michael

[holleymcfly]

Hi Michael,
good news, thanks for checking.
Maybe stupid question, but how will we get now a released version (1.8.12) to the official site? I don't want to use a self-built snapshot version in our productive environment...

Thanks,
Holger

[vaskrist]

Hi Holger,

well the only way you can do that is to ask the maintainers who have write access to master to merge the pull request and release a new version.

What I do right now is using your snapshot I built myself in some POCs right now. But I am used to using SNAPSHOTs temporarily (even a few months) in production until there is a released version. The version in the plugin manganement shows that I have built it, the date and the short commit hash I think.

On the other hand I don't handle the "production" Jenkins as a real production, I just do a backup in addition to using the JobConfigHistory Plugin and take a shot. This way I can move faster forward since there is still a lot of work to be done.

Michael

[crislacumba]

Hi,

I just saw that it is possible to call the httprequest from the Pipeline.
def response = httpRequest "http://httpbin.org/response-headers?param1=${param1}"
println('Status: '+response.status)
println('Response: '+response.content)

However, if I want to make a POST request with data in the body how can I do that?

Thanks!

Cris

[vaskrist]

Hi Cris,

this is the discussion pertaining to the pull request (a proposed change to the plugin) and not a place to ask arbitrary questions.

Next time please post questions on StackOverflow so that others may benefit from possible answers.
But even better - try to use Google first: http://stackoverflow.com/questions/37945370/how-to-post-json-data-in-body-with-jenkins-http-request-plugin-and-pipeline.

Michael

[janario]

Merged.

Thanks for the pull request.
I'm going to test with workflow build and I'll release it soon.