The last topic got auto-closed without a solution. But is a large issue for people migrating to Spaces support and trying to adopt it.
Ideally users who a Spaces admins should be able to clone a Project between two Spaces they administer. This task could either require identically named dependencies in the target Space. Or the cloned Project could just be missing Variable Sets or Tenant dependencies, and (Channel) Lifecycle dependencies could reset to default. Or for maximum bells, the dialog could list the dependencies and let users pick new ones in the target Space, or opts to remove/reset those dependencies.
In the absence of a cross-Space Clone option. In theory users should be able to use the Migration API to do roughly the same. However the page says this is not supported for Octopus Cloud, but it doesn’t say why or what the current limitation is?
Note: the migration API is not supported for migrations from self-hosted Octopus Server to Octopus Cloud currently.
Questions:
Is a cross-Space Project Clone function planned for the UI?
What is the technical problem with a Migration API and Octopus Cloud? What are the operations that we should avoid and why? Can the Migration API be used at all with Octopus Cloud?
Thanks for getting in touch, and for the thought you have put in to this post.
We currently don’t have any available method to migrate between spaces, as Octo.exe does not support exporting/importing between spaces, neither does Octopus.Migrator.
We will be introducing an updated tool to accommodate for inter-space migrations, however this isn’t available yet and won’t be for a little while (we have a few dependencies that we need to complete first to make this supportable and sustainable into the future).
As for using Octopus.Migrator or the Migration API to move from Self-Hosted to Hosted Octopus, the main issue is accounting for the required permissions changes that need to be made for Hosted Octopus. Specifically we reserve Administrator rights for Octopus service accounts, and to do that we have a new permissions type Octopus Administrator which the migrator can’t account for.
This is very much not supported, but the migrator should work OK with partial-exports of projects only, or we can provide a full migration service (which we perform manually) if you would prefer.
Thanks for the info @Alex.Rolley we’ll watch this space for the new Spaces-aware tools.
Once you crack that tool/API, a cross-Spaces Project Clone in the UI would be great, even if it just ‘casts off’ any unmet dependencies in the target Space.
I developed a python client tool to migrate the whole space to another space. This tool can also migrate the space to another space on a different server. I will share the tool if company allows.