Passing proxy config setting to octo CLI

[johnsimons]

Ensure we pass the proxy configuration set at the agent to the octo CLI and the REST call we do to check for latest.

Fixes #116

[johnsimons]

Do we want all versions to support proxy arguments? I’m not sure if previous versions of Octopus CLI support it.

@jbristowe I think so, it was added in v6.6.0 (7 May 2019)

[johnsimons]

Why not preserve includeArguments as-is? Why refactor the function at all?

Me being lazy and piggy backing on it, do you think we should do it differently?

[tdaniels-iowa]

After this release our Push To Octopus and Create Release tasks started breaking. We were using version 3 of the two tasks. In reviewing the previously working jobs it seems that now the proxy entry is being added. We do have a proxy entry file for the agent, however using the tasks for us doesn't doesn't require it and actually ends causing issue with those tasks when it is automatically included.

For anyone finding this comment, switching to version 2 of the two task corrected the errors because the proxy entry is not automatically included. We are also looking into the proxy bypass settings to exclude our Octopus instance URL's.

[johnsimons]

Hi @tdaniels-iowa,

I understand, so you have a proxy configured at the agent but that configuration is not supposed to be used for the Octopus URLs, is that correct?

I think in this case you need to configure bypass settings as you mentioned. Let me know if you configure this bypass it works as expected?

[ValdisThomann]

@tdaniels-iowa

We also ran into this problem. After some initial confusion about how to bypass the proxy, we discovered that we just needed to add a .proxybypass file to the agent directory as per https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/proxy?view=azure-devops&tabs=windows#specify-proxy-bypass-urls

@johnsimons I can confirm that configuring the .proxybypass file works as expected.

[ValdisThomann]

@johnsimons would it be possible to write some more information to the logs in this circumstance, to help other soft-headed muppets like myself?

For example, if the agent is configured to use a proxy and receives a http 504 response while executing an octopus command, augment the current "504 Gateway Timeout" error message with something like:

"Your agent is configured to use a proxy. If this command should not be sent via a proxy, you might need to add or modify the agent's .proxybypass file. See https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/proxy?view=azure-devops&tabs=windows#specify-proxy-bypass-urls."

[tdaniels-iowa]

Yes eventually we found the bypass file documentation and added our proxy server to it. Our challenge was in that we didn't make any network changes and suddenly a bunch of builds started breaking in our automated process. So it required us to go back review for any environmental / tooling changes and back-track those to try and find the issue. As @ValdisThomann stated a simple messaging difference would have made it much simpler to identify that process. Our issue is resolved for now, but I would suggest seriously considering that messaging mentioned above.

[ValdisThomann]

Yes eventually we found the bypass file documentation and added our proxy server to it. Our challenge was in that we didn't make any network changes and suddenly a bunch of builds started breaking in our automated process. So it required us to go back review for any environmental / tooling changes and back-track those to try and find the issue.

We had the exact same experience

[johnsimons]

@ValdisThomann @tdaniels-iowa thanks heaps for the suggestion on improving the logging, I have https://github.com/OctopusDeploy/OctoTFS/pull/202 to fix this.