Comments
2 comments
-
I figured it out.
It was my misunderstanding of the different steps. I thought the release creates the script for the deploy step. It is not the case. The deploy does the same as release in the way it calculates changes, only difference is that it applies them to the database.
Whatever parameters are specified in the release needs to be repeated in the deploy step to get the same results. -
Hi Johannes,
Thank you for taking the time to post the solution. I'm glad that's all sorted for you now.
If you have any further issues just let us know.
Add comment
Please sign in to leave a comment.
A script that was generated in one of the initial releases had a table rebuild process because the identity seed and increments are different in source control than in production. I stopped that build from running in production and configured the release step to ignore the identity increment and seed values.
I triggered a new release in Octopus and this worked perfectly fine because the script in the artifacts no longer wants to rebuild the table.
I then pushed it on to production, but it then times out because it tried to drop the primary key of the table it wanted to rebuild in the previous discarded release.
I ended up deploying the script found in the second release's artifacts manually to the database which worked fine.
Even now if I generate a new release with no new database changes it comes up with a script with comment lines that says there are no changes. This is expected, but if I push the build through to production it then again times out trying to drop the primary key of the initial script that was generated a few releases back.
How is it that the automation is executing something completely different than the scrip in its artifacts?