Octopusdeploy/octo 6.8.0 and 6.7.0 are not backward compatible

reliability
(Andrey Biryulin) #1

So 6.8.0 has been released 5 hours ago and it fails against same Octopus server that we haven’t touched comparing to 6.7.0
https://hub.docker.com/r/octopusdeploy/octo/tags

Command is like this:
Snippet

docker run --network=‘host’ -v pwd:pwd -w pwd --rm octopusdeploy/octo push --server http://myurl --apiKey=$APIKEY --package $dbZipFileName --replace-existing

Failure is like this:
Unable to process response from server: String ‘Wednesday, 19 June 2019 1:54 PM’ was not recognized as a valid DateTime… Response content: {
“Id”: “packages-gtp.db.gtp_migrations.1.79.0.20-feat.216430-timedoutorder-improvements”,
“PackageSizeBytes”: 157581,
“Hash”: “128342e9c5aab5a43ffad8db272ef181cc8512fc”,
“NuGetPackageId”: “gtp.db.gtp_migrations”,
“PackageId”: “gtp.db.gtp_migrations”,
“NuGetFeedId”: “feeds-builtin”,
“FeedId”: “feeds-builtin”,
“Title”: “gtp.db.gtp_migrations”,
“Summary”: null,
“Version”: “1.79.0.20-feat.216430-timedoutorder-improvements”,
“Description”: null,
“Published”: “Wednesday, 19 June 2019 1:54 PM”,
“ReleaseNotes”: null,
“FileExtension”: “.zip”,
“Links”: {
“Self”: “/api/packages/packages-gtp.db.gtp_migrations.1.79.0.20-feat.216430-timedoutorder-improvements”,
“AllVersions”: “/api/packages?nuGetPackageId=gtp.db.gtp_migrations”,
“Feed”: “/api/feeds/feeds-builtin”,
“Raw”: “/api/packages/packages-gtp.db.gtp_migrations.1.79.0.20-feat.216430-timedoutorder-improvements/raw”
}
}

I’m not 100% sure but our Octopus server very much likely might be running on Windows in New Zealand local time and locale.

2 Likes
(Andrey Biryulin) #2

And this command worked - telling it to use exactly 6.7.0:

docker run --network=‘host’ -v pwd:pwd -w pwd --rm octopusdeploy/octo:6.7.0 push --server http://myurl --apiKey=$APIKEY --package $dbZipFileName --replace-existing

1 Like
(Arman) #3

I’m having a very similar problem trying to push a package from Azure Devops build to our Octopus server using Octopus Extension (Package Application Task). In my case also Octo version. 6.7.0 was working fine 6.8.0 is failing with the same message:
2019-06-19T03:20:10.6168716Z Unable to process response from server: String was not recognized as a valid DateTime… Response content: {

“Published”: “Tuesday, June 18, 2019 10:20 PM”,

}

Error from Octopus Server (HTTP 201 Created)
Exit code: -7
##[error]Error: C:\hostedtoolcache\windows\Octo\6.8.0\x64\Octo.cmd failed with return code: 4294967289
##[error]Failed to push package. C:\hostedtoolcache\windows\Octo\6.8.0\x64\Octo.cmd failed with return code: 4294967289
##[section]Finishing: Push Packages to Octopus

(Markus Trachsel) #4

We have the same Issue. It seems that OctopusDeploy self updates. Does anyone know where this is handled?

(Brendan Kehoe) #5

Same for us doesn’t look like vsts extension was updated and we haven’t touched the octopus server

(Romain Coudray) #6

If you use the Tool directive, you can force the version to the latest working (6.7.0) :

#tool “nuget:?package=OctopusTools&version=6.7.0”

(Kieran O Sullivan) #7

We had the same issue with VSTS. Workaround for us was to set the Task Version to 2.* for all the octopus steps in the build config.

(Daniel) #8

Having the same issue with Azure DevOps.

#9

I’m using Azure DevOps . How do you specify the Tool directive? Does it go into the Additional Parameters?

(Justin Walsh) #10

Hi everyone!

Just letting you know that 6.8.1 has been released to resolve this issue. ADO/TFS/VSTS should pull down this version automatically if you are not specifying a prior version.

We sincerely apologize for the inconvenience caused by this bug.