Get Type type value error using API to update ReleaseNotes

Integration
1

Dear All,

We try to update the ReleaseNotes data through the Octopus API. The GET method to retrieve the releases works fine but when we do a PUT on the /api/Spaces-1/releases/Release-<xxx> we get the following error:

{
  "ErrorMessage": "Tiny type values should never be null. If the value you want to communicate is null then just pass a null rather than a tiny type wrapping a null. (Parameter 'value')"
}

With the GET call we know that the API key that we use is fine. We use the same path as for the GET call in the PUT call. The PUT cURL is:

curl --include --header "X-Octopus-ApiKey: API-XXX" --header "Content-Type: application/json" -X PUT "https://octopus.<local_server>/api/Spaces-1/releases/Releases-40568" -d'{"Version": "1.9.1.40", "ReleaseNotes": "Foobar"}'

We found a Github issue on Octopus Deploy that mentions something about the implementation using the TinyType library and that it has been fixed in the 2022 releases. However, we are running the v2020.6 version. (Converting Project To VCS is Throwing TinyType exception · Issue #7151 · OctopusDeploy/Issues · GitHub)

Is our issue related to this Github issue? And, is there a workaround for our release and this API call?

3

Hi @cleijtens.sbp,

I think this is a fairly cut and dry case of, yes it is likely that an upgrade will fix your issue here.
From what you’ve described and the error within the Github report, it definitely seems related.

You have a modern version of Octopus, so an upgrade should be fairly straight forward. Please check out our documentation on upgrading for a good step-by-step guide.

Please, also let me know if the issue still persists after the upgrade.

Regards,

4

Hello Dane,

Thank you for your quick response.

Internally another team is responsible for the Octopus service and they believe there is a lot involved on their end to perform the update.

Next to the reported issue, is there any internal evidence within your organization that this issue exists with that version of the API?

We are checking for other ways to get the same functionality in the meanwhile and then test this API call again as soon as our internal team has done the upgrade.

Cheers,

Christ

5

Hey Christ,

If you have the infrastructure available, you could look at spinning up a test instance and testing/migrating some of your projects there, for peace of mind.

Looking through the internal code changes relating to the issue, I can see the changes the engineers made were in the core module. This means that an API upgrade will likely not fix your issue, as the way that the release note are handled by Octopus is different.

Additionally, as the instance you are running is quite old, getting some engineering time for a workaround (other than the one stipulated in the Github issue) will be very difficult as 2020.x is no longer supported.

Sorry if this isn’t the news that you were chasing. Let me know if I can help further.

Regards,

6

Hello Dane,

I have followed your advice and created a trial cloud version of Octopus. Put a project in it and created a release of it. Created an API key and was able to perform the GET queries but again when trying to execute the PUT request we get an error. This time a different one:

“ErrorMessage”: “Object reference not set to an instance of an object.”

And we have not been able to find out why we get this error.

$ curl --header "X-Octopus-ApiKey: API-Z2DSOZNYBQLULD0SNOBU5THRLB1HY4X6" --header "Content-Type: application/json" -X GET "https://christ.octopus.app/api/Spaces-1/releases/Releases-3"
{
  "Id": "Releases-3",
  "SpaceId": "Spaces-1",
  "ProjectId": "Projects-1",
  "Version": "v3",
  "ChannelId": "Channels-1",
  "ReleaseNotes": null,
  "ProjectDeploymentProcessSnapshotId": "deploymentprocess-Projects-1-s-2-5558T",
  "IgnoreChannelRules": false,
  "BuildInformation": [],
  "Assembled": "2023-01-06T14:31:25.455+00:00",
  "LibraryVariableSetSnapshotIds": [],
  "SelectedPackages": [],
  "ProjectVariableSetSnapshotId": "variableset-Projects-1-s-0-PMPJT",
  "VersionControlReference": null,
  "Links": {
    "Self": "/api/Spaces-1/releases/Releases-3",
    "Project": "/api/Spaces-1/projects/Projects-1",
    "Channel": "/api/Spaces-1/projects/Projects-1/channels/Channels-1",
    "Progression": "/api/Spaces-1/releases/Releases-3/progression",
    "Deployments": "/api/Spaces-1/releases/Releases-3/deployments{?skip,take}",
    "DeploymentTemplate": "/api/Spaces-1/releases/Releases-3/deployments/template",
    "Artifacts": "/api/Spaces-1/artifacts?regarding=Releases-3",
    "ProjectVariableSnapshot": "/api/Spaces-1/variables/variableset-Projects-1-s-0-PMPJT",
    "ProjectDeploymentProcessSnapshot": "/api/Spaces-1/deploymentprocesses/deploymentprocess-Projects-1-s-2-5558T",
    "Web": "/app#/Spaces-1/releases/Releases-3",
    "SnapshotVariables": "/api/Spaces-1/releases/Releases-3/snapshot-variables",
    "Defects": "/api/Spaces-1/releases/Releases-3/defects",
    "ReportDefect": "/api/Spaces-1/releases/Releases-3/defects",
    "ResolveDefect": "/api/Spaces-1/releases/Releases-3/defects/resolve",
    "DeploymentPreviews": "/api/Spaces-1/releases/Releases-3/deployments/previews/",
    "Variables": "/api/Spaces-1/projects/Projects-1/releases/Releases-3/variables"
  }
}

And then the PUT:

HTTP/2 500 
date: Fri, 06 Jan 2023 14:46:17 GMT
content-type: application/json; charset=UTF-8
cache-control: no-cache
expires: -1
pragma: no-cache
server-timing: total;dur=44
content-security-policy: default-src 'none'; connect-src https://octopus.com https://telemetry.octopus.com 'self'; font-src 'self'; img-src data: https://www.gravatar.com 'self'; script-src eval: inline: https://extensions.octopus.com https://octopus.com 'self' 'unsafe-eval' 'unsafe-inline'; style-src inline: 'self' 'unsafe-inline'; worker-src 'self'; block-all-mixed-content; sandbox allow-same-origin allow-scripts allow-forms allow-popups allow-modals allow-downloads;
octopus-node: name=octopus-i055766-c6f7ff8f6-x4wsr; version=2022.4.8241
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
strict-transport-security: max-age=31536000; includeSubDomains

{
  "ErrorMessage": "Object reference not set to an instance of an object."
}

Maybe you can help us here?

Thanks,

Christ

7

Hi Christ,

I’m just stepping in for Dane to keep things moving since he’s currently offline.

We’ve reviewed the logs for your hosted instance to understand the cause of the error you’re seeing, and it looks like the cURL request you ran to update the release notes for the desired release was attempting a PUT with the version and build information. You’ll need the whole JSON object to PUT back in order to do this, and we have a great example API Powershell script on how to do this here:

Can you try this method instead and see if it allows you to update the release notes?

Let us know how it goes!

Best,
Patrick

8

Patrick,

Thank you for stepping in and the swift response. It was not clear that the entire JSON structure needed to be provided. But that is not a problem, we just copy it over and change the field we want to change. Could this possibly also be the issue for the first error we received regarding the TinyType error?

Isn’t it strange that the API returns a 500 HTTP status response code in these cases instead of something else?

Also the API documentation seemed to indicate that only the Version is a required field. Or did I interpret that incorrectly?

Thanks,

Christ

9

Hi Christ,

Sorry for the delay in getting back to you.

Could this possibly also be the issue for the first error we received regarding the TinyType error?

This is a possibility and it’s worthwhile checking that out if you don’t have an option of an upgrade. Engineers have spent a bit of time on surfacing the underlying errors in later versions of Octopus Deploy, however, I don’t think the error on your 2020.6 instance and your cloud instance are related. This may become more clear with the answer to the next question.

Also the API documentation seemed to indicate that only the Version is a required field. Or did I interpret that incorrectly?

If you are referencing the API documentation from your current version of Octopus, then this is a possibility. Mostly, with the more recent versions of Octopus, we settled on a more predictive formula for working with the API. API write commands will, when it makes sense, require submitting the entire JSON object. So in this particular case, you will pull the JSON object, manipulate the ReleaseNotes value and push the entire object back up to the server. With this formula, it make the API calls much more predictable and usable without having to resort to digging into documentation each time to find out exactly what is required for the API call to be successful.

Looking at the new errorMessage from the cloud environment, your PUT command will now be incorrect because the arguments are now quite different for the command to work.

Hopefully this makes sense. Please let me know if you have anymore questions.

Regards,

10

Dane,

I did some tests with the cloud trial version. Used the provided script above but that requires additional software on the Octopus windows worker. In our process step we used a REST function in PowerShell. That did not require this extra software.

However, testing it manually with a full JSON object to PUT it does work on both the cloud trial as our own Octopus install. So we are fine.

Thanks for all the quick and directed help that we received. I am impressed by your customer focus.

This thread can be closed.

Cheers,

Christ

1 Like
11

That’s fantastic news!
Thank you for letting me know the outcome and the kind words.

Happy Deployments!

13

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