I have an issue with the import export functionality. I have created some custom step templates which I have then used inside the process of a deployment project. This was done on my local development machine as I was learning octopus. I then tried to move the project and templates across to our deployment environment to check it all works there. I did this by creating a new octopus server, creating an environment and then exporting each of the custom step templates I had created and importing then into the octopus server by clicking on the import export links. So far so good.
I then used Octo.exe to export the project from my local instance and import it into the deployment environment server. It imported fine the problem, however, is that the IDs of my custom steps on the deployment server are now different to the Ids on my local server which means the imported project steps are pointing to the wrong custom steps.
I have many more custom steps locally that I created whilst testing things out and the real steps I wanted to export are numbered in the 20s whereas when I imported them into a fresh octopus they were imported starting at 1 rather than the id that was originally used. Hence, the issue with the project import. Is there a better way to export/import projects using custom steps apart from using backup and restores?
Thanks for getting in touch! This is great feedback, thanks for the report.
We only recently opened up step templates to be exportable, and in this situation there will be issue.
There is no real workaround for this, not better way to do what your doing.
This will soon be resolved with some changes we are making to Octopus behind the scenes so I won’t create a ticket.
The ‘fix’ will be part of 3.0.
We ran into this same issue recently with import/export and step templates. I was wondering if we changed the identifiers and version numbers in the exported JSON to their equivalent ids in the new OD server do you think that the import would correctly update the usage and link to the right step templates?
We fixed this temporarily by doing the following:
- On the destination OD Server we deleted all projects and step templates.
- On the source OD Server we Selected Browse RavenDB, Tasks, Export Database and exported everything. There is a bug in the RavenDB version used by OD that fails of you try to export only documents from selected document types.
- On the destination OD Server we Selected Browse RavenDB, Tasks, Import Database, Advanced. Checked Include only documents from… and Checked Action Templates.
- We then exited out and did a Repair RavenDB storage for good measure.
- Then we export and imported all projects between servers using the octo tool and all step templates were happy and using the right versions and values.
Very low level and scary and we are not sure what this might break but it proved there is a low level way to fix it (somewhat).
I think your idea of the approach to just change the JSON export with the equivalent IDs would have worked, but would have made the process extremely manual and error prone.
The export idea was a nice out of the box style solution. Assuming you have two due to network restrictions, the only issue I could see would be the two servers now sharing thumbprints.
While using this solution you will have to continue to create anything in the same order from one server to another to keep it working as needed.
I agree it’s scary and I wouldn’t recommend it too often, and lots of backups everywhere. I do understand your need as we don’t have a perfect solution for you right now.
Thanks for sharing your solution.
There’s a bug in the import application which doesn’t update the template identifiers during processing. You can just change the step template identifiers in the in the export json file to their new identifiers in the target database. To do this, look for the ActionTemplates member variable in the JSON export file. For each template references, look up the new id in the target Octopus server using the web api. The list of templates and ids can be found by just accessing the url: http://YOUROCTOPUSSERVER/api/actiontemplates. Do a global replace on the variable id values.
This is actually fairly scriptable if you find yourself doing this often.
This thread is a bit old right now and versions have changed from 2.x to 3.x could you let me know what version you are running and explain a bit more about the bug you are seeing so we can get a fix out if required.
A step by step for replicating the issue would be fantastic. Are you referring to our new 3.x export/import feature from the manager and not the import/export inside the library as this thread is talking about?