I am migrating to a new server from an old one, same config and code, different machine.
I am getting the following when trying to push a release from TeamCity to Octopus. This works in the old environment.
Running command: octo.exe push --server http://(server_address_here)/ --apikey SECRET --package C:\TeamCity\buildAgent\temp\buildTmp\ZipPreprocessor16489580444096368558\ew.infrastructure.0.0.1.252-925a6005.zip
13:18:08 Pushing packages to Octopus server
13:18:11 Octopus Deploy Command Line Tool, version 7.4.4
13:18:12 Detected automation environment: “TeamCity/2021.2.2”
13:18:14 Space name unspecified, process will run in the default space context
13:18:14 Handshaking with Octopus Server: http://(server address)/
13:18:14 Handshake successful. Octopus version: 2019.12.8; API version: 3.0.0
13:18:14 Authenticated as: Dev Ops Service Account (a service account)
13:18:14 Pushing package: C:\TeamCity\buildAgent\temp\buildTmp\ZipPreprocessor16489580444096368558\ew.infrastructure.0.0.1.252-925a6005.zip…
13:18:14 Requesting signature for delta compression from the server for upload of a package with id ‘ew.infrastructure’ and version ‘0.0.1.252-925a6005’
13:18:14 No package with the same ID exists on the server
13:18:14 Falling back to pushing the complete package to the server
13:18:14 The resource was not found on this server.
13:18:14 Error from Octopus Server (HTTP 404 NotFound)
13:18:14 Exit code: -7
13:18:14 octo exit code: -7
Is there any way I can diagnose this further? I can’t see what is not found, I’m pushing a new package. I tried adding the project variable to disable delta compression but that didn’t even seem to work (i.e. it’s still trying delta compression)
Thanks for reaching out!
Sorry to hear you’re having trouble after moving your Octopus Server.
I’d just like to confirm whether the Packages folder (C:\Octopus\Packages) was copied over to the new instance? Check out our guide for moving Octopus Server for more info about our recommendations but I feel that’s likely to be the cause of the issue. You will also need to restart the new Octopus instance to index the packages.
Disabling delta compression for the Project via a variable will effect the Release Deployment but not the octo push command to get the package from TeamCity to Octopus. To disable it for
octo push, try adding the flag
--use-delta-compression="False" to the command. Check out the Octo CLI push documentation for more info.
If that doesn’t help resolve the issue I’d be more than happy to take a deeper look into what’s going on!
Let me know how you get on or if you have any questions.
It got slightly further but ultimately failed with the same error.
Pushing package: C:\TeamCity\buildAgent\temp\buildTmp\ZipPreprocessor10678045717368028410\ew.infrastructure.0.0.1.253-925a6005.zip…
Requesting signature for delta compression from the server for upload of a package with id ‘ew.infrastructure’ and version ‘0.0.1.253-925a6005’
The delta file (12,719 bytes) is 61.05% the size of the original file (20,834 bytes), uploading…
Something went wrong while performing a delta transfer:
Falling back to pushing the complete package to the server
The resource was not found on this server.
Error from Octopus Server (HTTP 404 NotFound)
Exit code: -7
octo exit code: -7
I should also add that as I was also moving to a new database, I did the migration using export / import, rather than a new install connecting to the existing database.
But copying the package feeds seems to have worked, in that I can see the packages in the built in feed in the Libraries tab. But as mentioned above, there’s still an error trying to send. Anywhere I could find more detailed logs?
Thanks for that additional info, I think I have a good idea about what’s going on here.
I’d just like to confirm, when you mention that you migrated using Import/Export that you are referring to this service?
The Packages section mentions that the built-in feed isn’t included with the Export to avoid huge export bundles, and will need to be copied over using the API. We have an API script which will help complete the package sync between the two servers and hopefully resolve this issue! Please make sure to understand the script and take backups, just in case.
Feel free to reach out if that script doesn’t help resolve the issue or you have any questions!
No, I used Import / Export Data from the Octopus Manager on the server.
Would the same limitation of not including the packages apply here?
Are you saying that even once I have copied the packages data on the file system I’d still need to run the API script?
Using the old Export data option will only export the package information stored within the database, not the physical packages themselves.
To do that you would need to copy the Packages folder from the old home location (default C:\Octopus) to the new instance. Whilst doing that it may be worth copying the Artifacts and Task Logs folders too.
Once that is done, if you navigate to Library > Packages there will be a
Re-index Now option in the right-hand column. This operation will scan through the packages folder and ensure that package data contained within the database matches the physical files found in the packages folder.
When migrating Octopus Server to new machines we do recommend performing a database backup\restore rather than using the Export options as this is the only way to ensure that all of the data is preserved. Our guide on moving the server and database can be found here: Moving the Octopus Server and database - Octopus Deploy
Thanks for the reply. I retried the migration following all the steps in that document. The end result ended up being the same.
Should I run the tool from the build server command line in debug mode, will that give better info?
Is the path to the new server URL or the bindings for that URL configured differently from the old server at all? The error suggests that it is reaching the wrong URL when attempting the upload, so, I’m wondering if there could be anything there.
Enabling debug mode would definitely be worth a try to see if it adds additional information as to what is occurring prior to the error.
Some other tests that may be worth trying are:
- Heading to Library > Packages and attempting to manually upload a package. Would be interesting to see if the problem exists when adding packages completely or just with ones added from TeamCity.
- Similar to this, you could try downloading the octo cli and running the Push package command from a different machine and from the Octopus server itself. This would help identify whether there is any network funkiness getting in the way.
Yes the bindings are different on the new server to the old server. But TeamCity is pushing to the new url. Would there be something configured in the database referencing the old binding that’s causing a problem?
Octopus and Team City are on the same server, although TC is referencing octopus via an external url. Should be no network issues but I’ll try a few things manually.
This is the info I get trying to call the command line tool in debug mode.
This does seem quite strange.
It definitely is able to communicate with the Octopus server as it can retrieve the previous version of the package.
The problem seems to be when it attempts to send any data to the Octopus server. It fails to perform the delta upload and then fails on the full package upload.
Were you able to test adding this package directly via the UI in Library > Packages?
Also, would it be possible to test pushing a differently named package via the CLI? We’ve occasionally seen issues where a specific package ID fails to upload due to some bad data within Octopus, but other packages continue to work fine.
Thanks for your help. On further examination I found that accessing octopus via localhost:8088 instead of the named route worked. I then examined the route setup and found that I was calling the server via http rather than https and any non https calls were redirecting, which works on a GET but not on a POST. Changed the server url to https and now it works.
TL;DR: My fault not yours.
No worries, we’ve all been there.
Happy to hear you got it working
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.