Octo.exe deploy-release: Object reference not set to an instance of an object

devteam_octopus · 13 July 2021 07:41

Hi Everyone,

We have been successfully using a very old version (3.3.12) of Octopus, and we are now looking into the upgrade path.

Running on Windows on AWS, we have cloned our old Octopus Server instance and upgraded it to the latest version (Octopus.2021.1.7500). The information on the updated Octopus Server looks correct with our releases and we have generated a new API key etc.
On a separate Windows Server instance, we have installed the latest version of the Tentacles and Octo CLI.

We have successfully provisioned a Tentacle, and it is communicating with the Octopus Server, but when attempting to pull the current release of our software, the request is failing (I’ve turned on the debug):

Octo deploy-release --project=“project” --server=“http://10.0.22.177” --apiKey=“apikey” --releaseNumber=“0.0.5685” --specificmachines=“machine” --deployto=Development --waitfordeployment --deploymenttimeout=“01:00:00” --debug
Octopus Deploy Command Line Tool, version 7.4.3264

From the Octopus Server side, the Tentacle is visible with the correct thumbprint, but is “unavailable”. The connectivity health check is also timing out:
The client was unable to establish the initial connection within 00:01:00.

The Windows firewall for the tentacle seems to correctly allow traffic on port 10933, but I’m not sure how I can test that other than through the health check?
From the Octopus Server, the health check is successful if I ping the old original tentacle machine.

Any help would be very appreciated.
Thanks

devteam_octopus · 13 July 2021 08:29

I’ve made a little progress, and managed to get the communication on port 10933 working, so now the health check is successful from the Server to the Tentacle, but the original Octopus Server 500 response is still occurring.

paul.calvert · 13 July 2021 09:41

Hi @devteam_octopus,

Is the 500 error only occurring when attempting to generate a deployment using the CLI?

If you head into the Octopus UI and initiate a deployment from there does it also fail?

Regards,
Paul

devteam_octopus · 14 July 2021 01:26

Thanks Paul,
Initiating the deployment from within the Octopus Server UI, and the same exception “Object reference not set to an instance of an object.” is shown.

Kenneth_Bates · 14 July 2021 03:26

Hi @devteam_octopus,

Thanks for keeping in touch! I’m jumping in here for Paul as he’s currently offline as part of our UK-based team.

I’m sorry for the trouble you’re seeing here since your upgrade. I’m wondering if this release throwing this error was created prior to your upgrade? Does a newly created release also cause the same error?

These symptoms lead me to think it might be a case of this old release’s data (created in 3.3.12) wasn’t handled correctly somehow during the upgrade scripts. I think we’ll need to look at the data directly to see if we can spot what’s going on. Would you be willing to export this project, and send us that export? We can then import it locally and reproduce and look at the data directly.

The process of exporting a project is outlined in this doc page.

Would you be willing to upload that to Octopus.com while logged in with your Octopus ID, under your Support Files section, along with the password used on the export?

I look forward to hearing back!

Best regards,

Kenny

devteam_octopus · 19 July 2021 06:35

Yes, I’m guessing that it’s likely to be due to us wanting to upgrade from such an old version.
I’ve just created a brand new release using the external feed from the latest version of TeamCity, and Octopus is still throwing the same exception when attempting the deploy.
Our current license has expired, so we can’t upload the files to the Support Files section, and we’re waiting on the purchase of the new license for when we know that we can upgrade successfully.
Should I email the project export and password to support@octopus.com?

Thanks

paul.calvert · 19 July 2021 06:52

Hi,

Sending it through via email would be fine.

Also, ultimately, the solution here may be to upgrade in smaller steps rather than going to the latest version in one go.
So, would it be possible to try upgrading your instance to each major release and then re-test after each upgrade to see if you run into this problem?
Something like 2018.12 > 2019.13 > 2020.6 > 2021.1 would be a good choice.

Regards,
Paul

paul.calvert · 19 July 2021 08:59

After reviewing the project export it seems that the issue is because the ConnectivityPolicy is set to null within the project deployment settings and every release currently created.

What it looks like:

 "DeploymentSettings": {
    "DefaultToSkipIfAlreadyInstalled": false,
    "ConnectivityPolicy": null,
    "DefaultGuidedFailureMode": "EnvironmentDefault",
    "DeploymentChangesTemplate": null,
    "VersioningStrategy": {
      "DonorPackage": {
        "DeploymentActionId": "43241b26-659a-42d7-9884-6022b021659b",
        "PackageReferenceId": "4aa6ead1-d3f2-4924-9954-cf52cf92d93a"
      },
      "Template": null
    }

What it should look like:

  "DeploymentSettings": {
    "DefaultToSkipIfAlreadyInstalled": false,
    "ConnectivityPolicy": {
      "SkipMachineBehavior": "None",
      "TargetRoles": [],
      "AllowDeploymentsToNoTargets": false,
      "ExcludeUnhealthyTargets": false
    },
    "DefaultGuidedFailureMode": "EnvironmentDefault",
    "DeploymentChangesTemplate": null,
    "VersioningStrategy": {
      "DonorPackage": {
        "DeploymentActionId": "Deploy Web Api",
        "PackageReferenceId": ""
      },
      "Template": null
    }

Changing the Deployment Targets Required option (I assume changing any of the other options in there would work too) within the UI and creating a new release does allow the new release to work but does not fix the previous releases.

e.g.

system · 19 August 2021 08:59

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