I have a new Octopus instance which I intend to use for the purpose of upgrading 2.6.4 to 3.2.24.
I was able to run an initial import from raven to SQL - which so far looks good, and I am still in the process of testing things.
One of the tests that I am doing is trying to Export the SQL data and then Import it back,
The Export succeeds but the import (of the same data without any change being made) with or without checking the overwrite option just fails with the following error:
120 errors were encountered
The transaction will be rolled back
120 errors were encountered
Error: The previous command returned a non-zero exit code of: 1
Error: The command that failed was: “C:\Program Files\Octopus Deploy\Octopus\Octopus.Migrator.exe” import --instance “OctopusServer” --directory “C:\Octopus\Exports\test” --password “XXX” --overwrite
looking into the migrator log all of the errors would look like this:
2016-03-07 14:24:51.4379 1 ERROR Did not find deployment process ‘deploymentprocess-feeds-’ for C:\Octopus\Exports\test\Projects<PROJECT-X><PROJECT-X> - - - PreDeploy.ps1
2016-03-07 14:24:51.4379 1 ERROR Did not find deployment process ‘deploymentprocess-feeds-’ for C:\Octopus\Exports\test\Projects<PROJECT-X><PROJECT-X> - - - PostDeploy.ps1
This error is caused when your feed name matches your project name. It is a bug in the import/export where it matches the first name and in this case it should be matching a project and not a feed.
We do have a GitHub issue open to resolve it: https://github.com/OctopusDeploy/Issues/issues/2399
The current workaround is to make the feed name and project unique from each other.
Are you performing this task for backup purposes or different reasons?
Thanks for getting back to me.
Renaming the feed might be a good workaround for now.
I am performing this task as part of my tests of a new instance I have created for the purpose of upgrading 2.6 to 3.x.
Being able to export and import our data is something which we need to test and make sure we can do if needed.
For now we are using sql backup/restore, but I can think of future reasons why we would need to use the import/export tool once we go HA or would like to share data between 2 instances.
Is there any ETA for fixing the issue?
Sent from my iPhone
No there is no ETA on the fix. HA shouldn’t require this feature as it shares a database. But for moving between two instances yes it will be very handy.
Thanks I’ll keep this ticket open until you have the fix and then I can verify.
Just to make sure I understand – if I do need to use the import/export for sharing between instances and the fix is still not applied – I can still use the workaround (renaming the project/feed), right?
That is correct. It has been confirmed the workaround is valid.