I’m trying to migrate a single project between servers. The migration task appears to be working on the source server but it never resolves. It outputs about 200 lines of debugging information in ~5 seconds and then sits there running but not outputting any more debugging information to the log. The longest I ran it for was 30 minutes before cancelling. I’m not really sure how to debug this because it appears to be working (i.e. not failing) but it’s also not outputting any information to the log. Also it’s a single project, so I wouldn’t think it would take > 30 min to finish.
I tried migrating another project and it’s stopping at the same place. It appears to be running this query:
SELECT *
FROM dbo.[ServerTask]
WHERE ([ProjectId] IN (@projectids_0))
ORDER BY [Id]
Then this is the last line it outputs in the log:
Created D:\Octopus\Work\20181128150137-202530-18233\export\ExtensionConfigurations\UsernamePassword.json
Thanks for getting in touch! Which version of Octopus Server are you using? We’ve made a lot of improvements to the data migration tooling in 2018.9 and I would recommend upgrading. The problem may already be resolved, or at least I will be in a much better place to help you.
Exporting the current configuration for a single project would normally take a couple of seconds. However from that query it looks like you are exporting all the Deployments as well. Depending on the version of Octopus Server you are using, you can tell the migrator to ignore history. It would be interesting to see if this stalls in the same place.
If none of these ideas helps, I would be very happy to help you further, however I would need you to send me the whole migrator log file to support@octopus.com (it may have sensitive information). The log files are in the same folder as Octopus Server’s log files: https://octopus.com/docs/support/log-files
I would be really interested to know why you want to migrate the single project. Can you give me some background? The reason I ask is because we are researching how people use the migrator so we can make better tooling to fit those specific scenarios.
Is this what you meant by telling the migrator to ignore history? Changing these options didn’t affect anything.
I emailed you several of our latest migrator log files.
We have a production server and a development server. What we want to do is be able to quickly move a project from production to development so that we can quickly/easily test out some changes that we need to make to the production project but without breaking anything. It’s also useful to preserve the integrity of the production project setup i.e. the step templates and variables used in the project. At first we were attempting to do this manually using the Octopus Rest API but there is no way to transport the sensitive variables using it. Also it seems that the migrator is specifically made for this purpose, moving projects between servers, so it could be quicker to use than creating a manual solution.
Thanks for sending that process dump through. The thread has stalled at this call stack, which says it’s trying to copy the task log files from your source Octopus Task Logs directory to the export location.
Could you try with IncludeTaskLogs = $false and see if that unblocks the process?
If that helps, could you try putting your server in Maintenance Mode (Configuration > Maintenance), then setting your Octopus Server Node to drain tasks (Configuration > Nodes) and wait for all running tasks to complete. Now try the export again. Don’t forget to set everything back to normal once you’re done.
I’ll continue to investigate on my side in case we can come up with any other ways forward from here.
