octo push doesn't work and return exit code -7 for URL https://my-hosted-octopus/octopus/api

[gitsidgo]

Have been trying to push a package using octo push for URL https://my-hosted-octopus/octopus/api.
But it fails with the following logs

Octopus CLI, version 9.1.3

Detected automation environment: "NoneOrUnknown"
DispatchRequest: GET https://my-hosted-octopus/octopus/api
DispatchRequest: GET https://my-hosted-octopus/octopus/api
DispatchRequest: GET https://my-hosted-octopus/octopus/api
DispatchRequest: GET https://my-hosted-octopus/api/spaces
Exception of type 'Octopus.Client.Exceptions.OctopusResourceNotFoundException' was thrown.
Error from Octopus Server (HTTP 404 NotFound)
Exit code: -7

As you can see, the URL stripped off the context path /octopus in the last DispatchRequest.

We further tried with the plain curl command :

curl -s -X POST https://my-hosted-octopus/octopus/api/Spaces-1/packages/raw -H "accept: application/json" -H "X-Octopus-ApiKey: API-XXXX" -F data=@some-package.zip

It works fine with the curl command but fails with the octo cli push command.

[slewis74]

Hi @gitsidgo, in your example you have "my-hosted-octopus", is that an Octopus cloud instance you're referring to there? If so, removing /octopus from the server URL should resolve this. You'd have that value there if you're using a self hosted instance with a virtual directory, but for our cloud instances you should just need the host name. I.e. https://my-hosted-octopus should be enough.
Note, the /api on the end isn't actually required either, our client code will ignore it if it is there.

[gitsidgo]

@slewis74 Thanks for replying. It is not a managed Octopus. We've self hosted it on our infrastructure.

The /octopus context path routes the requests to the octopus instance. There are other services as well segregated via different context paths. So to communicate with that octopus instance, /octopus can't be omitted. But as we observed the client code ignores/trims /octopus and directly appends /api due to which it fails.

Is there a way that octo push cli could append /api after whatever context path it receives as part of --server option? Instead of omitting the provided context path

[slewis74]

Thanks, that's great context. We're working on trying to get an accurate reproduction set up. Our working theory, based on what you've described, is that you have a reverse proxy and when it sends the client's initial requests through to Octopus they don't have the /octopus.

Could we check a couple of things? Is that assumption correct, i.e. is there a reverse proxy between the browser and Octopus? If so, could we check what Octopus' ListenPrefixes look like? We're assuming the browser would see requests as https://my-hosted-octopus/octopus but Octopus might see the incoming requests from the proxy looking something like https://my-octopus-hosts-name?

If that's the case it would explain what you're seeing with the CLI. The first call it makes is to the /api route, to get the HyperMedia links back to tell it where the other routes are. If the proxy isn't including the /octopus in the forwarded calls then Octopus will send back incorrect links and the client will try to hit the wrong path (in the screen shot you sent it's trying to hit the Spaces link from the collection in order to work out what the default space is).

This would explain the behaviour of the CLI, but what's curious is that the Octopus portal works on the same mechanics. Is it working ok? Is it accessed through the same reverse proxy?

[gitsidgo]

@slewis74 Our octopus portal(UI) is running behind a VPN and to access the portal, we have to be on a VPN. The portal is not accessed using the same reverse proxy as suggested above. The portal works fine as there is no /octopus context path in it.

On the contrary while we use the CLI, we try to hit octopus on a different URL which is publicly accessible. But the portal is not exposed on the public URL. The screenshot that I've shared above is of this public URL and not the private URL on which the portal is exposed.

Assumption: by portal you meant Octopus UI console

[slewis74]

Ok, given that I think we understand why it's happening, it does relate to the calls going between the proxy and the Octopus API. Those calls get made without the /octopus and that is confusing Octopus when it is generating the Hypermedia for the CLI.

Would it be possible to add an additional ListenPrefix in the configuration for Octopus and have the proxy route slightly differently?

What we think should work is that if you add a 2nd listen prefix to Octopus that includes the /octopus on the end then it itself will accept incoming traffic with or without that directory. If the proxy then routes to Octopus using the /octopus path then the Hypermedia should end up correct and the CLI will work as expected.

The Octopus UI would be accessible with or without the /octopus.