I seem to have an issue, related to https://github.com/OctopusDeploy/Issues/issues/5054.
I have updated the default value of a variable in my step template, updated the deployment step, depending on my step template and now I can no longer access my project. The overview, process, triggers, channels, releases and settings page all show me the “The given key was not present in the dictionary.” exception.
(using version v2018.9.12)
How can I resolve this?
Thanks in advance!
We sincerely apologize for this.
The quickest way for us to resolve this issue is if you are able to upload a backup of your Octopus database. If so, you can upload it to this secure location. There is no need to supply your master key, so we won’t be able to see any of your sensitive data. Please reply to this thread once you have uploaded the file, as we are not automatically notified.
If you are unable to upload a database backup, then let me know and we’ll find another way of getting you back up and running.
I am having some issues uploading our most recent full backup file (+/- 900MB). The upload starts and after a while, it looks like the view refreshes and the pending upload is gone … showing me the original message “There are no files in this directory.” Or, once, when it did reach 100%, my browser became unresponsive, so I am not sure the upload succeeded.
Is there a filesize limitation or could I maybe use wetransfer?
I can see the uploaded file (913MB), so it seems the upload was successful.
The permissions on that location are set so that you can upload the file, but not see the uploaded files. This is how we allow secure, public uploading of files. Though that does sound like a confusing UI. I must admit I’ve never used it from that side.
We’ll restore your database and investigate first thing tomorrow (Australian time).
Can I ask which version of SQL Server you are using? (2014, 2016 2017, etc)
We’ve restored your backup and found the problem.
To cut to the chase, you should be able to resolve the problem by performing the following:
Stop the Octopus service
Execute the following SQL against the Octopus database
WHERE [ScriptName] = ‘Octopus.Core.UpgradeScripts.Script0133SyncActionTemplatePackageIds.cs’
Restart the Octopus service
This will cause the deleted upgrade script to be re-run when the server starts. In my testing this resolves the problem.
Please take a database backup prior, just in case.
I’ll give you some more details on exactly what went wrong here (but feel free to ignore):
In Octopus 2018.8 we added the ability for deployment steps to have multiple packages. In a few places in the application, we had previously relied on the assumption that referencing a step was the same as referencing a package (e.g. project version strategy, channel rules, etc). That assumption no longer held, so we had to update these places to explicitly reference a step and a package. Unfortunately, in doing so, we introduced a bug related to step template package ID’s getting out of sync with project deployment processes. The database update script we deleted above was intended to resolve this issue. It essentially synchronized the package ID’s between step templates, deployment processes, channel rules, and a few other places.
Looking at your data, you had an interesting situation that caused that script to not process your affected step template. Your ‘Deploy an evolution Console Template’ step template is based from a ‘Deploy a Package’ step, but it previously had no Octopus.Action.Package.PackageID property. And yet the deployment steps created from this template did have this property.
I’m not exactly sure how this would have happened. Possibly these steps were created via the API, rather than UI? Or possibly there was a version of Octopus in the past which allowed this.
Hopefully that restores your project to working order. Please let me know?
thank you for the quick response! I followed your instructions and its fixed
You are right about the API though … I’ve created a set of scripts which - after packaging the result of our build process - automatically creates an Octopus project group, the project itself, the deployment process, channels, etc.
The deployment process is a collection of step templates with only a few parameters and when it gets created, all the properties of the step template are copied into the deployment step, where ‘Octopus.Action.Package.PackageId’ is one of them. So for the moment it is quite unclear why this one was missing, but I’m glad it got fixed.