Azure DevOps - potentially breaking change in 'Push Package(s) to Octopus' (v4.2.491)

Azure DevOps Service version: 4.2.491
Azure Agent version: 2.192.0
Azure Agent OS: Windows Server 2019 build 17763.2183

Since updating to the latest version of the Azure DevOps Service on 6 Oct 2021, executing the task ‘Push Package(s) to Octopus’ (Task version 4) results in the ‘–proxy’ flag being added to the push command executed by the task. In our case, this change was breaking and blocked a part of our release pipeline.

Before:
octo.cmd push “–server=[server]” “–apiKey=[key]” “–package=[package]”

After:
octo.cmd push “–server=[server]” “–apiKey=[key]” “–package=[package]” “–proxy=[proxy]”

To the best of my knowledge, our proxy settings for this server haven’t changed. As such, I am speculating that the task now automatically detects user proxy settings (i.e. the user LAN settings configurable via Internet Explorer) and adds them to the command.

If my speculation is correct, this is a potentially breaking change. Could I suggest adding a checkbox to the task that allows users to opt-in to this behaviour, instead of providing it by default?

Please let me know if no such change exists and I will go and re-check my assumptions :slight_smile:

Thanks for your time,
Valdis

Hi @valdis.thomann,

Thanks for getting in touch!

We have noticed this behaviour following a change to allow proxy usage within the steps. The step is automatically detecting any proxy settings on the agent and applying these. The workaround for now would be to add a bypass to the agent proxy to allow connections to the octopus server to continue.

This has been raised with our engineers to see if it can be handled better, as we agree that it would make sense to have this behaviour controllable from the step configuration itself.

Regards,
Paul

Hi Paul,

Thanks for your quick response.

In this instance, I’m less concerned about what makes more sense in the step configuration itself. I wanted to bring to your attention that you’ve released a breaking change in what looks like a patch release. My suggestion was for how this functionality could have been introduced without disrupting your customers’ existing pipelines. Obviously bumping a major version of the task would have been another option.

Azure DevOps automatically installs the latest version of extensions and doesn’t afford the luxury of rolling back. We have already started the process for modifying the proxy config, but unfortunately this process is not as quick and trivial as it should be at some of your customers’ sites.

I want to be clear about the impact of this latest change for this particular customer:

  • Breaking the release pipeline, preventing any releases from being pushed to Test and Production.
  • Consuming time and resources to identify and resolve the problem, that might have otherwise been put to better use.

Cheers,
Valdis

1 Like

Hi @paul.calvert

Could you please elaborate further on what ‘any proxy settings’ means in this context? Specific detail about how the task detects these settings, from what sources, and in what order of priority would be very useful.

Cheers,
Valdis

In case it is useful, this is the actual change that was made and the issue that it was fixing.

As I understand it, the details will be drawn from those used when initially configuring the build agent
e.g.

./config.cmd --proxyurl http://127.0.0.1:8888 --proxyusername "myuser" --proxypassword "mypass"

If you experiencing different behaviour, let me know and I’ll raise it with our engineers.

1 Like

Thanks @paul.calvert , that was very useful. I had previously searched for the repo without success - I didn’t think to search for ‘TFS’.

We have resolved the issue.

I misintepreted your initial response

As a suggestion to modify the configuration of the proxy itself, not the agent’s proxy configuration.

The specific resolution was to configure the agent to bypass the proxy by adding a .proxybypass file as per Run the agent behind a web proxy - Azure Pipelines | Microsoft Docs

1 Like

@paul.calvert I just wanted to add that now that I actually understand how it’s working, it seems less important to have this configurable via the TFS/DevOps step if a more useful error message could appear in the logs.

I’ve added a suggestion to the change conversation.

Thanks again for your prompt assistance with this issue.

1 Like