Activity overview
Latest activity by Andrew P
If someone else is experiencing this issue - open up the Nuget package and look at what's inside - in some cases TeamCity has produced empty Nuget packages - so when they get to Octopus and our plugin tries to deploy them it cannot do so and runs into this error. To fix this - make sure that TeamCity (or whatever build system you're using) is creating a Nuget package from the correct path (rather than an empty path) / comments
If someone else is experiencing this issue - open up the Nuget package and look at what's inside - in some cases TeamCity has produced empty Nuget packages - so when they get to Octopus and our plu...
Hey Jeet, Deploy a Package is the correct first step - you have to specify the Package ID [image] After the deploy a package - then you would use the Redgate - Create Database Release step template to create the update script and report, and the Redgate - Deploy Database Release step template to run the update script.(probably with a Manual Intervention or Review step in between)[image] Hope that helps! Cheers, / comments
Hey Jeet,Deploy a Package is the correct first step - you have to specify the Package IDAfter the deploy a package - then you would use the Redgate - Create Database Release step template to create...
Hey Communited, Ignore Collations is a SQL Compare Option instead of a Filter - below is a screenshot of how you can add that to the deployment. [image] Filters are for specific objects or object types - Options are for specific sql syntax. Cheers, / comments
Hey Communited,Ignore Collations is a SQL Compare Option instead of a Filter - below is a screenshot of how you can add that to the deployment.Filters are for specific objects or object types - Opt...
There's a way to skip the dependency check via PowerShell but it is not surfaced in the Extensions - link to the PowerShell
That would create a project object then you could pass that to the New-DatabaseBuildArtifact and it would just package up that object without any validation.
Which is one reason we don't surface it - we don't want to encourage customers to do a build with no validation - it doesn't fit with the DevOps/shift left/fail fast mindset. Often times there are ways to do build validation successfully but it requires some creativity, like building on a Dev instance for cross-database dependencies that have not yet been introduced into Test. (PS the Release does not do any dependency validation) Cheers, Andrew / comments
There's a way to skip the dependency check via PowerShell but it is not surfaced in the Extensions - link to the PowerShell
That would create a project object then you could pass that to the New-D...
Yep you can change the Transaction Isolation Level in the Release. If you are using the PowerShell then it is just the -TransactionIsolationLevel switch in the New-DatabaseReleaseArtifact cmdlet If you are using the Release Extension it would look like this: [image] / comments
Yep you can change the Transaction Isolation Level in the Release.If you are using the PowerShell then it is just the -TransactionIsolationLevel switch in the New-DatabaseReleaseArtifact cmdletIf y...
Thanks for your post! By default, it uses one long transaction for the Build, with XACT_ABORT ON, so the whole script is rolled back if any part of it fails. I'd recommend using/adding the NoTransactions Comparison option to the Build Definition. Since a Build is purely for validation, its not really worth it to have in one long transaction if it runs into Distributed Transaction errors. Cheers, / comments
Thanks for your post!By default, it uses one long transaction for the Build, with XACT_ABORT ON, so the whole script is rolled back if any part of it fails.I'd recommend using/adding the NoTransact...
Hey David, You would need to set up a Filter to exclude Users and put the path to the filter inside the Build task (under the Filter Path parameter. During the Build - it is using the Invoke-DlmDatabaseSchemaValidation cmdlet, so the documentation here is also relevant. If you are already using a Filter to exclude Users in SQL Source Control, then you can reference that path which would look like %system.teamcity.build.workingDir%\filter.scpf Hope that helps! / comments
Hey David,You would need to set up a Filter to exclude Users and put the path to the filter inside the Build task (under the Filter Path parameter.During the Build - it is using the Invoke-DlmDatab...
This depends on your network topology - as long as the tentacle can access the SQL Box then it does not need to be on the same machine. Though if it is over a VPN or the network access is slow/limited, then having the tentacle on the SQL Box would be better to minimize latency. There isn't a best practice on this, it is more about the security context (is it on another network not accessible to the current tentacle?) with some minor performance concerns if the network latency is high. Warmly, / comments
This depends on your network topology - as long as the tentacle can access the SQL Box then it does not need to be on the same machine. Though if it is over a VPN or the network access is slow/limi...
Hey Holla, You need to either use a hosted database, or a local database - if you are setting it up to connect to a local database then you need to configure a private VSTS Agent locally - more info. Make sure to configure the Build to use that Agent - and that the Agent has appropriate permissions to the Server/DB. Hope that helps! / comments
Hey Holla,You need to either use a hosted database, or a local database - if you are setting it up to connect to a local database then you need to configure a private VSTS Agent locally - more info...