I am exporting single Project with partial-export tool, with unique Name (its name is not repeated among other Spaces) and when I export it everything seems fine: I have single Project exported, single Channel, single Lifecycle etc. BUT I have exported list of all environments among other Spaces as well.
This seems really not well - since all environments (regardless if they are repeated or not among the Spaces - I have them all). They are even referencing some other Spaces ID so I am concerned those environments from other Spaces will be imported as well on production, or something will be messed up on the second environment once I import this on that environment.
My SPACE ID for the Project is Spaces-43. But it exports from all other spaces like this: Spaces-1.DEV Spaces-1.DR Spaces-1.PROD Spaces-1.TEST Spaces-42.UAT Spaces-42.PROD Spaces-43.UAT Spaces-43.PROD
This is the command which I used: Octopus.Migrator.exe partial-export --instance=OctopusServer --project=“ADM GLOBAL” --password=test --inline-scripts=LeaveInline --ignore-tenants --ignore-deployments --ignore-machines --directory=C:\Temp\Export2
This seems really serious bug to us for production!
Thanks for reaching out. Could you let me know the use case for your export/import is? It’s possible you should be using a different tool than the Octopus.Migrator. We have another one called SpaceCloner. It has a lot of information to digest, but its a pretty robust tool. There are caveats and warnings though, so please read everything before going forward with using it.
Please let me know if you think SpaceCloner will be a good fit for what you’re trying to do.
thank for your feedback but I am really not quite sure about your response.
I was checking couple of time on the Forum, and it was always suggested to use partial-migrator tool.
We have Octopus instance where we have one relevant space with many projects, and 2 environments, and many variables. We want to migrate that configuration into the new space on Octopus Production system which is already used by our company for different teams etc. So that Production system already has many spaces, projects, environments etc.
Once we do the migration from our DEV instance to PRODUCTION Octopus, we want to migrate only the projects with variables, life cycles and environments which we created within that space on DEV. We do not care of course for all other spaces and environments, since many of there where for education and development purposes.
So I really cannot understand why are all Environments exported? As I mentioned - lifecycles and channels and projects are correctly exported. I do not want environments from different spaces since my project with unique name does not reference of course those environments from other spaces… Also I think it will mess up the things if I try to import something into already existing Prod Space (what will happen if Production system already has those Spaces-IDs). I really don’t what to mess up the production. Sorry but it really does not make too much sense to import all environments from all spaces in DEV to PROD which already has its own spaces and environments… Why are they exported at all?
Is this regular behavior? Or I did maybe something wrong? Can’t understand really…
Maybe you cannot resolve this bug (I think this is a bug), but is then supported workaroud to delete all the environments and exported file which do not belong to my environment? I would like to keep only evironments from Spaces-43. Spaces-1.DEV Spaces-1.DR Spaces-1.PROD Spaces-1.TEST Spaces-42.UAT Spaces-42.PROD Spaces-43.UAT Spaces-43.PROD
I asked few questions regarding the migration and it was answered to me that migrator tool (partial export) is the best option for doing this…
any advices please?
Is this a bug that it exports environments from all Spaces?
Can I delete manually, before the import, env files from Spaces which should not be exported at the first at all?
Unfortunately, that tool is not updated to work with spaces. What you’re seeing is the symptoms of that underlying problem. I can’t fully recommend using it for this use case as you may run into issues if you go down this path. You are more than welcome to attempt what you’re doing but I would create a backup in case anything goes wrong. You may end up with unintended data inconsistencies or worse. Our documentation on the migrator tool needs to be updated to reflect the lack of support for spaces, and I have put this on my to-do list.
Have you had a chance to look at SpaceCloner and see if that’s an avenue you could go down to achieve what you’re doing?
now I more confused than before, because I do not know what exactly means that it is not updated to work with spaces.
I want to export ProjectA (unique name) from SpaceA.
On some previous Topic it was mentioned to me that I can do the export of that ProjectA it just needs to have unique name in order not to be exported from other Spaces (if that name exists, correct?)
Since folder Spaces is also exported, I supposed it will create new Space on production environment as well, correct? Please confirm.
And since environments from other spaces are exported as well - would you recommended more to import it as it is or to remove those files with spaces from other environments? Since I checked, and those Spaces and Environments are not referenced on any other place within the exported files?
Looking forward for your reply and instructions. I will check additionally second tool but I supposed that this partial-migrator tool is officially supported?
Can I export from some space which is not Default and import it into Production Space. I supposed this was quite regular and normal scenario.
While we do support the Octopus.Migrator tool, we do not support it for the function you are attempting to use it in.
A supported use case of this tool would be exporting a project from Instance A(Default Space), then importing it to Instance B(Default Space). Anything outside of that scope is not supported or intended.
That doesn’t mean you can’t do some modifications and test it, but the tool was not meant for this and it may cause you issues, so we don’t recommend or support it.
You would need to manually edit files from the export before you import them to the other instance to make the data line up correctly, which is dangerous and cause unintended side-effects.
I have updated the documentation to reflect that the tool does not support this functionality, I apologize that it wasn’t current and thorough.
While I realize this isn’t ideal, we are working on some future changes that will make this easier, but for now, we recommend using SpaceCloner. SpaceCloner is open-source so you can view and modify the code to fit your scenario. As always, we suggest a test migration before attempting this on production instances. There is a lot of information regarding its usage and warnings about potential issues so please read it thoroughly.
Please let me know if you have any other questions, and sorry for the confusion.