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

Proxysettings inside project configuration #95

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

adripo
Copy link

@adripo adripo commented May 17, 2019

Added proxy (with credentials) settings for each project.
It can be chosen between inheritance from jenkins ( /pluginManager/advanced ) and custom proxy configuration.

@jakub-bochenski
Copy link

Thanks for the pull request.

Could you please describe your use case? I can understand why one would want different proxy settings than the ones used for UC, but defining this per project seems like an overkill to me.

I think proxy settings is something that would be best handled on the agent (slave) level, not on project level.

@jakub-bochenski
Copy link

On the technical level, please cover the parts you are changing with unit tests. You can check recent PRs by @proski for examples

// }
// }
// }
if (Jenkins.getInstanceOrNull() != null && proxy != null) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point of checking Jenkins.getInstanceOrNull() now that the code uses the proxy field?

@@ -81,6 +83,7 @@ public StashBuildTrigger(
String projectPath,
String cron,
String stashHost,
JSONObject proxySettings,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the JSONObject type required here?
It is basically a Map<String,Object>
I would prefer to use proper, strongly typed DTOs here

</f:radioBlock>
<f:radioBlock name="proxyChoice" value="custom" title="Custom" checked="${(instance.getProxySettings() != null) ? instance.isProxyType('custom') : false}">
<f:entry title="Proxy Host" field="proxyHost">
<f:textbox value="${(instance.getProxySettings() != null &amp;&amp; instance.isProxyType('custom')) ? instance.getProxyDetails().getString('proxyHost') : ''}" />

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is significant repetition here
I would expect jelly has some kind of a block/panel element that would enable you to hide irrelevant fields with one toggle

@@ -125,6 +129,50 @@ public String getStashHost() {
return stashHost;
}

public JSONObject getProxySettings() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are those getters needed? I think I only see getProxy() being actually called

@proski
Copy link

proski commented May 23, 2019

Ideally, we should configure Bitbucket servers in the global configuration and select one of them in the project configuration.

Speaking of the unit tests, it's a tangled mess. StashApiClient is written in a way that makes it hard to test. It can be cleaned up, but that's a lot of work.

Stash Notifier plugin has much better code for interacting with Bitbucket. It uses the latest client code. It supports proxies. It also supports HTTPS certificates, which makes sense, as the code is one of the most valuable resources in the company and should be protected. The code also avoids having a separate context variable that #68 introduces. There are good unit tests for the code. So it's something we should consider using.

@jakub-bochenski
Copy link

. The code also avoids having a separate context variable that #68 introduces. There are good unit tests for the code. So it's something we should consider using.

You mean lift the code from Stash Notifier plugin instead of the changes in #68?

@proski
Copy link

proski commented May 24, 2019

. The code also avoids having a separate context variable that #68 introduces. There are good unit tests for the code. So it's something we should consider using.

You mean lift the code from Stash Notifier plugin instead of the changes in #68?

I plan to try it eventually. Maybe we could use the unit tests code first.

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