After updating to Octopus 3, I can’t create releases anymore!
Here’s the beginning of the error message:
Error while executing SQL command: Violation of PRIMARY KEY constraint 'PK_VariableSet_Id'. Cannot insert duplicate key in object 'dbo.VariableSet'. The duplicate key value is ($variablesets-databases).
The statement has been terminated.
The command being executed was:
INSERT INTO dbo.[VariableSet] (OwnerId, Version, IsFrozen, Id, Json) values (@OwnerId, @Version, @IsFrozen, @Id, @Json)
What could be the problem?
Thanks for getting in touch! Could you tell me a bit about your upgrade process? Did you have a beta 3.0 running that you re-used the database before import?
We haven’t had this issue reported with anyone on 3.0 so there is a chance something is wrong with the data.
Are you just attempting to create a release of an existing project? Does it happen for all projects or just one?
Did you have any errors or warnings when you imported your data?
Let me know what you find,
I updated straight from v. 2.6 without testing a a beta version of 3.0. I used the guide at http://docs.octopusdeploy.com/display/OD/Upgrading+from+Octopus+2.6 and used Approach 2 (In-place upgrade of an existing server).
Yes, I’m trying to create a relase of an existing project. It happens on all existing projects but one.
I didn’t notice any errors or warning during the import. The import wizard reported success when the process finished. Perhaps there is a log from the import wizard that could tell us more?
Considering the error message:
INSERT INTO dbo.[VariableSet]
… I suspect the problem lies with my variables? I do have a set of legacy variables, some originating from the deprecated Red Gate Deployment Manager which I migrated from last year. The project that still works only uses a small set of variables, in contrast to the other projects.
Just discovered something while fiddling around with my variables:
If I remove the General settings (connection strings etc.) variable set from the Included Variable Set, the release creation starts to work again!
I do need that variable set, though, so I’m still stuck.
However, inspecting the variable set, I’m reminded of the way I’ve set up one connection string for each environment, with the same variable name repeated for each environment but with a distinct scope for each variable instance, see the attached screenshot.
This worked fine in Octopus 2.6 and earlier, but perhaps this usecase isn’t covered in v. 3? If not, how should I configure my connection strings instead?
What we saw in your original message was this weird key that we don’t usually define or name as such
$variablesets-databases so that’s why the questions.
It’s very possible is has come over from RM and we just don’t handle the data correctly in 3.0. Is it a large variable set? I would suggest recreating it directly in 3.0 and adding it back to your projects to see if it resolves the issue for you.
Sorry for the troubles.
I removed the faulting variable set and replace it with a couple of new variable sets. Fortunately, there were only about 15 variables in that original set so it was not that much work.
Result: I can create releases again!
My use of the same variable name for different scopes works fine too, so I was barking up the wrong tree there. The error had to do with that
$variablesets-databases definition, just like you pointed out.
Thank you for the help!