• See README.md
• PYPI Octopus-python-client
• Video instructions on YouTube

octopus_python_client -h

octopus_python_client_gui

MacOS issue

log file octopus_python_client.log is in the execution folder

• -user user_name (optional)
• -pass password (optional)
• -m octopus endpoint root pem file path (optional)
• -k api_key (optional, needed if user/pass do not exist)
• -ow overwrite if present, overwrite the existing items without asking
• -ns no_stdout if present, disable all stdout
• -d path to store the local Octopus server data -d=current will use the current running path
• -o the Octopus endpoint including /api/
• -a action (please see the code or -h for all actions supported)
• -s spaces id or name, also the subfolder name for the items inside this space; if no spaces id specified, the command will download all items inside and outside spaces; and save them under "outer_space"

• by user_name and password

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -user=guest -pass=guest -s=Spaces-1 -a=get_types -m=/path/file.pem

• by api_key

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_types -m=/path/file.pem

source octopus server information is for cloning from server to server and they are optional for cloing from space to space on the same server

• -sre source octopus server endpont

• -srd local path for the source Octopus server data

• -srk source octopus server api key

• -sru source octopus server user name

• -srp source octopus server user password

• -srm source octopus server pem file path

• -srs source space name or id (it is for both cloning space to space and cloning from server to server)

• -ld indicate the source server/space is local data files and you are cloning from local data files to a destination server/space

• Clone all cloneable types from space to space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space -srs=source_space -s=destination_space

• clone tenants + tagsets

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space -srs=source_space -s=destination_space -ts=tenants,tagsets

• Clone single item and its all dependencies from one space to another space: project "some_project"

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space_item -srs=source_space -s=destination_space -tp=projects -nm=some_project

• source_space on source_server to destination_space on destination_server

octopus_python_client -sre=https://source_server/api/ -srk=SOURCE-API-KEY -srs=source_space -o=http://destination_server/api/ -d=current -k=DESTINATION-API-KEY -s=destination_space -a=clone_space
octopus_python_client -sre=https://source_server/api/ -srk=SOURCE-API-KEY -srs=source_space -o=http://destination_server/api/ -d=current -k=DESTINATION-API-KEY -s=destination_space -a=clone_space -ts=tenants,tagsets
octopus_python_client -sre=https://source_server/api/ -srk=SOURCE-API-KEY -srs=source_space -o=http://destination_server/api/ -d=current -k=DESTINATION-API-KEY -s=destination_space -a=clone_space_item -tp=projects -nm=some_project

Clone from Spaces-1 in Octopus server A to Spaces-2 in Octopus server B

• Step 1: get all data types in Spaces-1 of Octopus server A:

octopus_python_client -d=path_to_server_A_folder -o=https://octopus_server_A/api/ -k=API-KEY -a=get_types -s=Spaces-1 -ow

• Step 2: run commands for cloning the whole space, a few types, or one item

octopus_python_client -srd=path_to_server_A_folder -d=path_to_server_B_folder -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space -srs=Spaces-1 -s=Spaces-2 -ld
octopus_python_client -srd=path_to_server_A_folder -d=path_to_server_B_folder -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space -srs=Spaces-1 -s=Spaces-2 -ld -ts=tenants,tagsets
octopus_python_client -srd=path_to_server_A_folder -d=path_to_server_B_folder -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_space_item -srs=Spaces-1 -s=Spaces-2 -ld -tp=projects -nm=some_project

• Export: if the Octopus server is on-premise and external Octopus server cannot access, you can migrate it to another external Octopus test server and download the migration package and later you can upload the migration package to the internal on-premise Octopus server

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create -tp=migrations/partialexport -bn=export_settings -nm=migration_export_task_response

• Import the project (from the migration package uploaded by the export server) If the Octopus server is on-premise and external Octopus server cannot access, you can migrate it to another external Octopus test server and download the migration package and later you can upload the migration package to the internal on-premise Octopus server

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create -tp=migrations/import -bn=import_settings -nm=migration_import_task_response

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create_release -s=Spaces-1 -rv=1234.4567.90 -pj=some_project -cn=some_channel -nt="{'packages':{'package.alpha': '20.0225.1714', 'package.gamma': '20.0325.0839'},'release_versions':'release_versions.beta'}"

• -rv release_version: optional, it must be unique and be never used if present; if absent, will use the Release Version setting in project
• -pj project_name: required
• -cn channel_name: optional, if absent, will use the default one automatically
• -nt notes: optional, it can be used to store a python dictionary format to input user specific package versions instead of the default ones. for the above example, 'release_versions':'release_versions.beta' asks the tool to load the packages/versions overwrites from the variable set 'release_versions.beta', instead of using the default ones loaded from the deployment process template; 'packages':{'package.alpha': '20.0225.1714', 'package.gamma': '20.0325.0839'} let user overwrites the packages/versions directly and this will also overwrite the ones loaded from the variable set named 'release_versions.beta'

use a release_id to create a deployment

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create_deployment -s=Spaces-1 -ri=Releases-1234 -en=some_environment -tn=some_tenant -cm="your comments"

use a project_name to create a deployment (create a deployment against the latest release in this project)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create_deployment -s=Spaces-1 -pj=some_project -en=some_environment -tn=some_tenant -cm="your comments"

• -ri release_id: optional, the output from create_release; if missing, you need -pj=some_project
• -en environment_name: required
• -tn tenant_name: required
• -cm comments: optional

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=create_release_deployment -s=Spaces-1 -rv=1234.4567.90 -pj=some_project -cn=some_channel -en=some_environment -tn=some_tenant -cm="your comments" -nt="{'packages':{'package.alpha': '20.0225.1714', 'package.gamma': '20.0325.0839'},'release_versions':'release_versions.beta'}"

• the argument explanation see above two commands

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=task_status -s=Spaces-1 -id=ServerTasks-12345

• -id task_id: required
• return task status: Success, Failed, Executing etc

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=wait_task -id=ServerTasks-12345 -tl=3600

• -tl time_limit_second: optional; time limit in seconds while waiting for the task to be completed; default is 600 seconds
• return: the final task status

• Get configurations and settings from a few spaces you have permission to access in a Octopus server

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=get_spaces -sps="my space,Spaces-1,Spaces-22" -ow

• Get configurations and settings from all spaces you have permission to access in a Octopus server

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=get_spaces -ow

• Get all configurations and settings from outer space in a Octopus server

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=get_types -ow

• Get all configurations and settings from Octopus server under a space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_types -ow

• Get all configurations for a certain type

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_type -tp=home
octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_type -tp=spaces

• Get all configurations for a certain type under a space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_type -tp=projects

• Delete all configurations for a certain type under a space If some configurations are referenced by other configurations, you may need to delete the referencing configurations first (delete all packages through command below)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete_type -tp=tagsets

• Delete all cloneable types under a space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete_types

• Delete specified types under a space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete_types -ts=tenants,tagsets

• Get one configuration for a certain type by using the name

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get -tp=tenants -nm=some_tenant_name

• Get one configuration for a certain type by using the id The item without a name is mostly a child item of a parent item, like deployementprocesses is a child item of a project (you can also get the child item by using the parent item name)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get -tp=deploymentprocesses -id=deploymentprocess-Projects-901

• Update an existing configuration for a certain type by using the local configuration file

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update -tp=projects -nm=some_project_name

• Update an existing configuration for a certain type by using the id The item without a name is mostly a child item of a parent item, like deployementprocesses is a child item of a project

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update -tp=deploymentprocesses -id=deploymentprocess-Projects-901

• Create a new configuration for a certain type by using the local configuration file

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=create -tp=projects -nm=new_project -bn=base_project

• Clone a new configuration for a certain type based on an existing configuration for the same type in the same space

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=clone -tp=environments -nm=cloned_environment -bn=base_environment

• Delete a configuration for a certain type it may throw error showing the configuration is used/referenced by other configurations, so you may need to delete the reference configuration first

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete -tp=tagsets -nm=tagset_to_be_deleted

• Merge a configuration for a certain type from the local file

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update_merge -tp=tagsets -nm=soem_tagset_name -ck=Tags

• Get a child configuration of a parent item by using the parent_name, parent_type, child_type, and child_id_key

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=get_child -pt=projects -pn=parent_name -ct=deploymentprocesses -ck=DeploymentProcessId

• Update a child configuration of a parent item from the local child file by using the parent_name, parent_type, child_type, and child_id_key (e.g. 'DeploymentProcessId')

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=update_child -pt=projects -pn=parent_name -ct=deploymentprocesses -ck=DeploymentProcessId

• Clone a child configuration of a parent item from another parent by using the parent_name, base_parent_name, parent_type, child_type, child_id_key (e.g. 'DeploymentProcessId'), and sub_item_key (e.g. 'Steps'. sub_item_key is for extracting the content in the child item. The content is the data changed)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_child -pt=projects -pn=parent_project_name -bp=base_parent_project_name -ct=deploymentprocesses -ck=DeploymentProcessId -sk=Steps

• Clone a project including the deployment process based on an existing project

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=clone_project -pj=cloned_project -bn=base_project

• Update the variable sets for a project by adding a suffix for the variable sets names and matching the new variable sets; -as means adding the suffix

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update_variable_sets -pj=some_project -as=suffix_name

• Update the variable sets for a project by removing a suffix for the variable sets names and matching the new variable sets; -rs means removing the suffix

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update_variable_sets -pj=some_project -rs=suffix_name

• Update the variable sets for a project by removing a suffix and then adding a suffix for the variable sets names and matching the new variable sets; -rs means removing the suffix, -as means adding the suffix

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=update_variable_sets -pj=some_project -rs=suffix_name -as=suffix_name

• Get a project (can be done by -a=get too)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=get_project -pj=some_project

• Delete a project (can be done by -a=delete too)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete_project -pj=project_to_be_deleted

• Delete projects in specific project groups excluding certain projects

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -s=Spaces-1 -a=delete_projects -pgs="Project Group 1,Project Group 2" -eps="Excluded Project 1,Excluded Project 2"

• Clone a deployment process step from an existing step by using the project name, new step_name, base_step_name, prev_step_name (for insertion location of the new step)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=clone_process_step -pj=some_project -sn=new_step -bs=base_step -ps=previous_step

• Delete a deployment process step by using the project name and step_name (to be deleted)

octopus_python_client -d=current -o=https://demo.octopusdeploy.com/api/ -k=API-KEY -a=delete_process_step -pj=some_project -sn=step_to_be_deleted

An Octopus API client tool across the different platform to manage Octopus server: get, update, process, server migration

• An Octopus client tool running on all platform/OS, instead of just PowerShell/C#.
• Team has full control of the tool and can customize it based on the team's needs.
• An Octopus server/space migration tool is missing on the market and this tool is going to solve it. The existing import/export tool cannot do the job for space to space migration and does not work if the source server and destination server are the different versions.

• PowerShell
• C#
• For migration, here is the hacky way: Octopus site/server migration

• Get and keep all server configurations/settings as a source of truth locally or in a repository
• Create new entities from local file
• Clone new entities from the server entities of the same type in the same space
• Modify/update the existing server entities
• Delete entities
• Migrate the server entities from space to space and also from server to server

• get all types
• get one type of entities
• get single entity by name
• get single entity by id
• get single entity with child entity
• get a project

• create a new entity by name using the local file
• create a new release
• create a new deployment

• clone a new entity by name from the same type on the same Octopus server
• clone a project including deployment process
• clone a deployment process step from an existing step

• update an entity by name using the local file
• update an entity by id using the local file

• delete an entity
• delete all entities of one type
• delete a project
• delete a deployment process step

• get a child entity by parent name and type
• clone a child entity of a parent entity from another parent
• update a child entity by parent name and type from a local file

• migrate types from one space to another space
• migrate types from one server to another server
• export the project to another Octopus server using Octopus import/export APIs
• import the project using Octopus import/export APIs

• Merge an entity
• Update the variable sets for a project by adding or removing a suffix

Migrate the Octopus server from one space to another space can including these types (the types below may not be up to date):

• basic types which have no dependencies on other types: 'actiontemplates', 'artifacts', 'certificates', 'dashboardconfiguration', 'environments', 'feeds', 'interruptions', 'machinepolicies', 'machines', 'proxies', 'subscriptions', 'tagsets', 'teams', 'libraryvariablesets', 'workerpools' etc
• complex types which have dependencies on other types: 'workers', 'lifecycles', 'projectgroups', 'projects', 'tenants', 'channels', projecttriggers etc
• child types which must be migrated after parent types are migrated: tenantvariables, variables, deploymentprocesses
• other types which cannot be migrated easily or may not be necessary to migrate: accounts, events, machineroles/all, packages, useronboarding, dashboard, dashboard/dynamic, deployments, tasks, variables/names

Octopus server types/entities are represented as a tree. The leaves are basic types that have no dependencies on other types. When migrating these types from space to space, we do not have to worry about the links, dependencies or references among them. We can just create them into a new space from a local file by calling the "POST" API. Below is an example of a basic type:

Id: Environments-21
Name: alpha
Description: ''
SortOrder: 3
UseGuidedFailure: false
AllowDynamicInfrastructure: false
SpaceId: Spaces-1
ExtensionSettings: []
Links:
  Self: /api/Spaces-1/environments/Environments-21
  Machines: /api/Spaces-1/environments/Environments-21/machines{?skip,take,partialName,roles,isDisabled,healthStatuses,commStyles,tenantIds,tenantTags,shellNames}
  SinglyScopedVariableDetails: /api/Spaces-1/environments/Environments-21/singlyScopedVariableDetails
  Metadata: /api/Spaces-1/environments/Environments-21/metadata

Some other types have references/links/dependencies to the other types. So when we creating them into the new space, we need to rebuild the links to the existing types in the new space. We must strictly follow the dependencies hierarchy and creating the new types one by one from children to parents. In the old space, the links/references/dependencies are mostly like:

- Id: Tenants-34
  Name: abc
  TenantTags:
  - FeatureFlags/DEF
  ProjectEnvironments:
    Projects-48:
    - Environments-1
    - Environments-2
    Projects-5:
    - Environments-2
  SpaceId: Spaces-1
  ClonedFromTenantId: null
  Description: null
  Links:
    Self: /api/Spaces-1/tenants/Tenants-34
    Variables: /api/Spaces-1/tenants/Tenants-34/variables
    Web: /app#/Spaces-1/tenants/Tenants-34
    Logo: /api/Spaces-1/tenants/Tenants-34/logo?cb=2019.10.4

In order to migrate Tenants-34 to the new space, we need to find the names of Projects-48, Environments-1, Environments-2, and Projects-5 in the old space. Through these names, we can find their new ids in the new space, and replace these old ids in the YAML payload with the new ids in the new space.

Child types need post-processing, such as deploymentprocesses, variables, and tenant variables.

Id: variableset-LibraryVariableSets-481
OwnerId: LibraryVariableSets-481
Version: 1
Variables:
- Id: 918aba37-212d-7faa-729c-d4e6bc6e5148
  Name: ssd
  Value: null
  Description: null
  Scope: {}
  IsEditable: true
  Prompt: null
  Type: String
  IsSensitive: false
ScopeValues:
  Environments:
  - Id: Environments-4
    Name: Dev
  Machines:
  - Id: Machines-282
    Name: DWeb02
  Actions: []
  Roles:
  - Id: EShopOnContainers
    Name: EShopOnContainers
  - Id: K8S Admin
    Name: K8S Admin
  Channels: []
  TenantTags:
  - Id: Hosting/Dedicated
    Name: Dedicated
  - Id: Hosting/Shared
    Name: Shared
SpaceId: Spaces-1
Links:
  Self: /api/Spaces-1/variables/variableset-LibraryVariableSets-481

Initially, I investigated each complex type which has links to other types and developed the code to aim for the dictionary locations which contain links and replace the links with the new links. The code is lengthy and error-prone. Later, I came up with a new idea and improved the migration script dramatically: Build an id_to_id_map while creating types in the new space. For the same entity of a type, the key is the old id in the old space and the value is the new id in the new space. For the types to be cloned, I store the id as the key and item payload as the value in another map, id_payload_map.

ActionTemplates-1: ActionTemplates-195
Channels-10: Channels-265
Environments-1: Environments-121
LibraryVariableSets-1: LibraryVariableSets-159
Lifecycles-1: Lifecycles-125
MachinePolicies-1: MachinePolicies-84
ProjectGroups-1: ProjectGroups-186
Projects-2: Projects-206
TagSets-1: TagSets-184
Tenants-10: Tenants-318
WorkerPools-1: WorkerPools-145
Workers-2: Workers-171
feeds-builtin: Feeds-1108
teams-spacemanagers-Spaces-1: teams-spacemanagers-Spaces-144

Treat any type blindly as a python dictionary, run a recursive search. Whenever a string is found, search the string as the key in the id_to_id_map, if the string is a key in the id_to_id_map, replace the string with the value in the map. If the string is a key in id_payload_map, replace all ids in the payload with the new id and post the payload to the new space. It is a recursive call and it will run until all child types are created. In some special payload, the key in the payload dictionary could be an id too, like the above tenant type example. Replacing keys in the dictionary while iterating the dictionary is dangerous and should be treated carefully. Please see methods __replace_ids() and __clone_item_to_space. The new idea reduced the code complex and reduced the code by hundreds of lines. One minor issue: if someone names an Environment as id style like "Environments-100", not "Beta", "Gamma", it could break the replacing id logic.

The type of channels is a bit special. the name is not unique: channel "Default" could be in different projects, so we use both channel names and project id to find the match. The type of releases is similar. "releases" has no name and is unique by "Version" and "ProjectId".

For some types, minor preparation processing is needed. Tenant Tags (tagsets) __prepare_tag_set (a bit complicate); __prepare_project and __prepare_library_variable_set (we do not want to clone the child items first; child items will be created automatically when the parent item is created)

Child types need post-processing, such as deploymentprocesses, variables, and tenant variables. Migrating projects, tenants, and libraryvariablesets will create empty deploymentprocesses, variables, and tenantvariables. The migration tool needs to run post-processing to "PUT" the child types after migrating the parent types.

Recursively clone only required tags wherever the tags referenced in other items; use tag's canonical name as the key and value in the src_id_vs_dst_id_map. Now we do not need to clone all tags first before cloning other items. The tenant tags are created on the fly with any entities linking to the tenant tags. Because tenant tags do not follow the style of the rest Octopus entities. The most Octopus entities generally have id/name, and when they are referenced, they are referenced by id like Channels-1. However, when tenant tags are referenced by other entities, they are referenced as the actual canonical name like Pod/TenantSun, so you do not have to know the id to find the link and you can directly create the tenant tags when you see the link. If the destination space already has the same tagset, each tag of each tagset must use the destination Tag ID not the source Tag ID, so we have to replace each tag id with the destination ones, otherwise, it shows"Tag Id is in invalid format." What about additional Tag ID in the source space? Do we need to remove the ID from the source tag? Yes!!!

You can use user_name/password instead of API-KEY to log in and call Octopus APIs. You do need to explicitly put user_name/password or api_key in the configuration file shown below. These values should be specified in the command line.

{
  "octopus_endpoint": "https://demo.octopusdeploy.com/api/",
  "octopus_name": "octopus_demo_server",
  "user_name": "guest",
  "password": "guest",
  "api_key": null
}

• interruptions
• artifacts

• add workaround for variables/all (504 Gateway Time-out) and clone variables; TODO: remove the workaround after fixing https://help.octopus.com/t/504-gateway-time-out-on-getting-all-variables/24732
• Octopus bug: PUT variables does not return ScopeValues
• Add workaround for a bug in Octopus: PUT a runbook with null RunbookProcessId will remove RunbookProcessId from destination space; that should not happen and it is different from other data types in Octopus
• RunbookProcesses (https://demo.octopus.com/swaggerui/index.html#/RunbookProcess/getRunbookProcessById shows the API is run runbookProcess and missing "es")
• Octopus treats string case insensitive for item names (I added a temp fix for it)

• LibraryVariableSets-100 has many versions, so need to sort and write versions one by one; but it seems not very useful for the destination space to keep all versions; so just put the last version.
• Wherever "Version" is seen in the payload, it must match "Version" from the new space by calling "GET" first before running a "PUT" operation
• clone_child can handle both deploymentprocesses and variables
• Story on __replace_ids: when the input is 10 items, only 9 of them are replaced with the new ids; Reason: when key is an id, we pop the value and assign the value to the new key. This could cause an unexpected result while iterating the dict. The solution is to iterate the deep copy of dict.keys() not dict.items()
• Fix cloning runbookProcesses
• Add clone accounts (removing the null token)
• Add clone build-information
• Get all users extended information
• Use fake_space flag to explicitly identify cloning server to server
• improved delete: delete the unused sub-items when the item cannot be deleted due to some sub-items are used
• Fix when the reference item ids are broken due to the removed reference item; Better solutions: 1. fix the source space by removing the broken reference ids; 2. download the whole space into files, remove the broken id from file, and clone by files (just like cloning from one Octopus server to another); Some broken reference is not item ids, but item names; it is very hard to replace them, so if clone failed due to the broken reference, please fix the source space first before cloning;

• fix the workaround for VersioningStrategy in the project; TODO once the migration supports clone packages; we do not have to pre-process VersioningStrategy
• For replace_ids, what if a key is a dict?