Oh, sorry for the misunderstanding. If you have limited egress to the outside internet from that machine (only allowing whitelisted URLs, or needing a proxy configured etc), it could be an environmental problem outside of ADO/Octopus. You can likely test this by RDP’ing into that machine, and then doing an
Invoke-WebRequest g.octopushq.com/LatestTools
and checking to see the output, which should look like:
StatusCode : 200 StatusDescription : OK Content : {"latest":"7.4.3116","downloads":[{"template":"https://download.octopusdeploy.com/octopus-tools/{version}/OctopusTools.{version}.{platform}-{architecture}{extension}","location":"https://download.octo…
RawContent : HTTP/1.1 200 OK
Date: Mon, 22 Feb 2021 20:02:24 GMT
Connection: keep-alive
Set-Cookie: __cfduid=df4a90c5bfc2e6b82fce63c7ffc8bf6b11614024144; expires=Wed, 24-Mar-21 20:02:24 GMT; path=/; domain=.octopu…
Headers : {[Date, System.String[]], [Connection, System.String[]], [Set-Cookie, System.String[]], [ETag, System.String[]]…}
Images : {}
InputFields : {}
Links : {}
RawContentLength : 1827
RelationLink : {}
If it fails to connect, then I imagine it’s an environmental issue that’s preventing the Octopus Plugin to get the latest version of the Octopus CLI.
If the above doesn’t work, I’d have your server/network teams take a look at why this request is failed. If you need to get this deployed now, I’d suggest adding the “Octopus CLI Installer” step to your job, and using the “Embedded” version there, so it won’t try to go out and pull down the latest version (and fail).