Error pushing packages from Azure DevOps to Octopus Deploy

Integration
1

I’m trying to push packages from Azure DevOps to an on premise Octopus Deploy instance. The Azure DevOps agent is also on premise and the server the Azure DevOps agent is running on is behind a firewall and doesn’t have outside access.

When running the Push Packages to Octopus step I am getting the following messages:
bacc6ade-c1c2-467d-a4ba-c1e9f875c68e exists true
Attempting to contact https://g.octopushq.com to find latest CLI tools
##[error]Error: Request timeout: /LatestTools
##[error]Failed to push package. Request timeout: /LatestTools
##[error]The operation was canceled.
##[section]Finishing: Push Packages to Octopus

I installed the Octo tools locally on the build server using these instructions: https://octopus.com/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension/install-octo-capability

I can see the Octo capability is registered on the server:
image

I don’t want the Octopus step “Push Packages to Octopus” to try and update itself to the latest CLI tools. How can I troubleshoot my issue?

4

Hi Kyle,

Thanks for getting in touch! You should be able to get around this by adding the Octopus Tools Installer step at the start of your build and specifying embedded as the version. This should avoid any attempts to download octo.exe externally.

We have a small section on this in the following documentation page.

Let me know if you have any questions here, or run into any issues.

Best regards,
Daniel

5

Setting it to “embedded” worked. Ideally I would like to not need the Octopus Tools Installer step.

I haven’t been able to to get the “Install Octo as a Capability” working. I believe I have everything installed correctly so that it should be detected as a capability and the Push Packages step should just work. What is being set by the Octopus Tools Installer step that tells the Push Packages step that “octo” is available?

Thank you for your help!

7

Hi Kyle,

Thanks for the update! I have some input from a developer on this.

It adds the version of Octo which is embedded along with the installer task to the tool cache and adds it to the path. The only difference in how the tool is resolved between the installer task and other tasks is that we don’t embed Octo for those due to Azure DevOps Extension size limitations.

If Octo has been installed as a capability it should use that version automatically since all paths to resolve Octo as a tool uses the VSTS/ADO tasks library to do so. This means adding an installer task at the start of the deployment process with the version of embedded is the closest in terms of behavior to v2 of the extension which embedded Octo into every task.

The only cause we can think of as to why the tool won’t be resolved when installed as a capability is due to the build agent not being restarted. It may report that it’s installed properly as a capability at that point, but won’t work at deployment time until the build agent is restarted.

If you have any questions here, please feel free to let me know.

Best regards,
Daniel

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.