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?