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.
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
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.
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.
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.
@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.
