Hi Alex,
What are you doing seems reasonable. I haven’t yet had a chance to create a test environment to mimic yours, but to answer your questions:
is there way to watch that particular deployment through api requests to see when it’s done?
Yes. The deployment object has a TaskId
property. With this, you can make a GET request to /api/tasks/{id}
. The Task object returned has a State
property, which you can inspect. I would recommend polling the task, and wait for it to complete.
Is there a way to increase timeout between octopus server and tentacle?
Yes. For Tentacle/Server communications, we use a library called Halibut. It has a number of default timeouts that can be overridden by config.
<add key="Halibut.ConnectionErrorRetryTimeout" value="00:15:00"/>
<add key="Halibut.TcpClientConnectTimeout" value="00:02:00"/>
<add key="Halibut.TcpClientHeartbeatSendTimeout" value="00:02:00"/>
<add key="Halibut.TcpClientHeartbeatReceiveTimeout" value="00:02:00"/>
The config lines above are those I believe most likely to be relevant to your situation. These should be added to the appSettings
section of Octopus.Server.exe.config
, located by default at C:\Program Files\Octopus Deploy\Octopus
.
I’ll briefly explain what each of these value does, and you can see the default values in the code.
ConnectionErrorRetryTimeout
: If an error occurs when sending message, and Halibut believes it is safe to retry, it will retry up to 5 times, or until this timeout is exceeded. Increasing this value will allow your failed messages to be retried for longer.
TcpClientConnectTimeout
: When there are no connections in the pool, or the pooled connections have expired, Halibut makes a new connection. This timeout applies when making this connection.
TcpClientHeartbeatSendTimeout
and TcpClientHeartbeatReceiveTimeout
: When taking a connection from the pool, small heartbeat request/response messages are sent to verify the connection is still valid. These timeouts apply to this process.
is there a way to set retention policies in a such way that it won’t store any packages on the tentacle ?
No. It will always persist the packages from at least the latest release. You’re right, you should be able to remove the package files yourself. You shouldn’t need to touch the DeploymentJournal (it will skip the package file if it doesn’t exist) and in general I wouldn’t recommend it.
I hope this helps! Don’t hesitate if you have any more questions.