As part of our deployment process we require to drop and rebuild a database. We are using the script found here and for troubleshooting purposes have replaced the variables with hard coded values to ensure that this is not the source of the problem.
Our deployment step is failing with the error (full trace attached):
Exception thrown
Failed to connect to server 127.0.0.1:1433.
Exception: Microsoft.SqlServer.Management.Common.ConnectionFailure
Exception: Failed to connect to server 127.0.0.1:1433.
—> System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.
However! Using the same code in the octopus script console results in the connection being made and the database being dropped as we would expect.
Can you advise what, if any, differences there are between the script console and the deployment step?
Thanks
octopuslog.txt (6 KB)
Hi Darren,
Looking at the error message, it is failing to connect to SQL Server running on the local machine (i.e. the Tentacle is installed on the SQL Server). Based on that, my initial suspicion is that when running via the Script Console you are targeting the correct Tentacle, whereas when running as a deployment step it is not executing on the Tentacle you expect.
When deploying to the environment that is failing, are there multiple machines in that environment? If so, is your database-drop-rebuild step restricted to run only for certain roles? And is the SQL Server instance the only Tentacle with this role?
Would you also be able to attach a full task log of a failing deployment?
Regards,
Michael
Hi Michael, thanks for your reply.
In addition to this I’ve tried updating variable form localhost to the IP address of the machine the database is on with no success.
The environment only has one machine associated with it, and this is the same machine that the console script is executed against.
I’ve attached a log of both the deployment and the console script to this post. We added in some powershell debug so you can see that both scripts are being executed on the same machine (RECEIVING).
scriptconsolerawlog.txt (1 KB)
buildrawlog.txt (16 KB)
This is puzzling.
In terms of execution, there is no difference between a script run via the console vs as part of a deployment process. Calamari (our deployment engine) doesn’t even know whether a script is being run via the console. The only change is the variables available.
Is it possible you are not creating a new release before creating a new deployment, and therefore using a different version of the script than the one being run via the console?
I can see from your log that the deployment process is running the script on the machine named ‘Specflow Testing’. This is the machine SQL Server is installed on?
As I mentioned, we’ve removed the variables and just hard coded in the values to make sure this wasn’t the source of the problem.
As for creating a new release before deployment - I’m fairy certain we’re doing that but to make sure; Our current process uses Jenkins to build our application and push to the Octopus nuget repo. We then use automatic release creation to create a release on our dev environment. From here we deploy to the acceptance testing environment which the “specflow testing” machine is a part of (where we’re seeing our problem). I’ve been creating a release by triggering a build in Jenkins each time I make a change to the script.
And yes, SQL server is installed on that machine, it’s the same machine I can successfully run the script against using the console.
Edit Not sure if it’s worth mentioning (and I can’t see why this would be the issue as I don’t imagine Octopus cares) but, we have the environments running on the same virtual machine, deploying to different folders etc…
Just a long-shot: is it possible the ‘Run on’ field of your script-step is set to ‘Octopus Server’, rather than ‘Deployment Target’?
If not, then I’m rather baffled. Would you like to schedule a support-call? Being able to share a screen often makes things clear.
Michael, apologies about the month in between posts. I’ve been away from work/this project and no one has picked it up (also I managed to forget however it was I posted this question)
The script step is set to run on the deployment target, and debug that we’ve placed into the script shows that it is indeed running on the correct machine.
I’m going to take another look over this thread and see if there’s anything we’ve missed, but if not, yes I will schedule a call.
Thanks.
No problem Darren.
I’ve also re-read this thread, and I can’t think of anything else to add.
If you can’t resolve the issue, we’d be happy to try and assist via a call.