[JENKINS-76271] In case of error in an http request, to log also de returned data

[akash-manna-sky]

JENKINS-76271

n case of error in an http request, to log also de returned data

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[akash-manna-sky]

Can you please review this PR? @MarkEWaite

[MarkEWaite]

Can you please review this PR? @MarkEWaite

I don't plan to review this pull request.

I'm not generally considering enhancements for this plugin. I think that users should use shell steps and run command line programs like curl and wget rather than embedding HTTP requests into their Pipeline. I became a maintainer of the plugin because I needed to complete some other tasks and I was willing to help.

@strangelookingnerd has been a great help, but I suspect that he is also not a user of the plugin.

If you'd like to adopt the plugin, I'm happy to offer some limited coaching on what it means to adopt the plugin.

[akash-manna-sky]

Can you please review this PR? @MarkEWaite

I don't plan to review this pull request.

I'm not generally considering enhancements for this plugin. I think that users should use shell steps and run command line programs like curl and wget rather than embedding HTTP requests into their Pipeline. I became a maintainer of the plugin because I needed to complete some other tasks and I was willing to help.

@strangelookingnerd has been a great help, but I suspect that he is also not a user of the plugin.

If you'd like to adopt the plugin, I'm happy to offer some limited coaching on what it means to adopt the plugin.

Then can you please suggest some repositories where you are active and accept new pull request? I am interested working on backend related tasks (not front end or visuals changes). @MarkEWaite

[MarkEWaite]

Then can you please suggest some repositories where you are active and accept new pull request? I am interested working on backend related tasks (not front end or visuals changes). @MarkEWaite

Not really. Here are a few that you might consider, though with the understanding that my interests may change at any time:

• [JENKINS-76261] Please reconsider forcing HashKnownHosts=yes git-client-plugin#1702
• [JENKINS-73427] With 'Accept first connection' host key verification, and JGit, newly added known_hosts entries are malformed git-client-plugin#1686
• [JENKINS-71122] incorrect assumption in search for ssh on Windows git-client-plugin#1668
• [JENKINS-72450] Support alternate ssh implementations on Windows git-client-plugin#1676

[h3nr1-d14z]

better late than never — the plugin had no active maintainer when you opened this, that's sorted now (adoption went through last week, #342) and the old queue is being worked through.

The change itself looks right: it only reads the body once the build is already failing, skips the read when consoleLogResponseBody already logged it, and the throw right after means nothing downstream needs the stream. I rebased your branch onto current master (the surrounding error handling was reworked in #343, but responseCodeIsValid itself is untouched — no conflicts) and force-pushed, so sorry for the history rewrite.

I also added tests on top: default-config failure now asserts the body lands in the build log on both freestyle and pipeline (fails without your change), and the consoleLogResponseBody case asserts the body isn't logged twice.

Merging once CI is green. Thanks for the patience.

— h3nr1-d14z

[h3nr1-d14z]

putting one design choice on record now that this is merged: the error-body logging fires on any status-code failure, including for users who deliberately left consoleLogResponseBody off. I kept it that way on purpose — when the build already failed validation, the response body is usually exactly what you need to debug it, and that was the whole ask in #330. the opt-in path (consoleLogResponseBody: true) still exists and logs the body before validation.

if anyone's in a spot where error payloads carry secrets that can't land in build logs, say the word and I'll gate this behind a flag.

— h3nr1-d14z