Tentacle Registration not auto triggering deployment

Octopus Server
, , ,
1

Hi,

After recent upgrade of octopus deploy server to latest version i am having trouble with auto deploy to environment which are not in defult channel.

\tentacle.exe register-with --instance “Tentacle” --server $octopusServerUrl --tenanted-deployment-participation “Untenanted” --environment $registerInEnvironments1 --environment $registerInEnvironments2 --environment $registerInEnvironments3 --environment $registerInEnvironments4 --environment $registerInEnvironments5 --environment $registerInEnvironments6 --environment $registerInEnvironments7 --environment $registerInEnvironments8 --environment $registerInEnvironments8 --environment $registerInEnvironments9 --environment $registerInEnvironments10 --environment $registerInEnvironments11 --environment $registerInEnvironments12 --environment $registerInEnvironments13 --role $role --role $role2 --role $registerInRoles3 --name $instanceId --apiKey $apiKey --comms-style “TentacleActive” --server-comms-port “10943” --force --console | Write-Host

the above scripts registers many environments with the server they all register sucessfuly but the only once with auto trigger deployment are the once from default channel life cycle.

Please find attached the audit log from server and the machine id which i have issue is Machines-4068ProcessAutoDeployments.log (1).txt (216.5 KB)

Note the same script used to work for older versions of octopus deploy I am not sure which was the older version we were using befoe this upgrade but now we are using 2019.13.7.

Please help me.

Thanks,
Ashish

3

Hi Ashish,

Thanks for getting in touch! I’m very sorry to hear you’re hitting this unexpected issue since upgrading. I’ve been able to reproduce this bug (thanks for providing such thorough information!) and raised a report at the following link for you to track.

The only workaround I can think of at the moment is to add the required environment to the lifecycle the project’s default channel uses, but that’s certainly not ideal. I’m sorry for the inconvenience and confusion this issue has caused you. If you have any questions or concerns going forward, please don’t hesitate to reach out. :slight_smile:

Best regards,

Kenny

4

Hi Kenny,

Thanks for the response. This has become a real show stopper for me. Is it posible for you to check which version this bug was introduced and if I can roll back to the version before that.

Thanks,
Ashish

5

Hi Ashish,

Thanks for following up, and I’m sorry for the delay in getting back to you on this one. I set up a local instance running 2019.11.3, which is the latest fast lane release before some major changes to auto deploy processing were made in 2019.13.0 (here’s the issue). I wasn’t able to reproduce in that version, so it seems like this is a regression introduced with that change. I’ve also confirmed it works are intended in 2019.12.8 LTS if you’d prefer that version. You can find the downloads to these previous versions at the following link.

Alternatively to rolling back, I had luck working around this issue in 2019.13.7 by adding the specific environment to the lifecycle that the default channel uses, if that helps in your setup. You could add this as an optional phase to prevent interruption to the progression the lifecycle currently follows.

I hope this helps, and please don’t hesitate to reach out if you have any questions or concerns moving forward!

Best regards,

Kenny

6

Thanks Kenny, I had to add all the environment to default and work around for now. Hopefully the issue will be resolved soon.

Thanks,
Ashish

7

Hi Ashish,

You’re quite welcome, and good to hear you’re able to workaround this temporarily. I’m sorry again about the inconvenience this issue has caused.

Best regards,

Kenny