New-DatabaseReleaseArtifact and IgnoreAdditional option

JTR

Hi, 
I'm testing database deploys from RG source control (via build artifacts).  I want to use IgnoreAdditional  option because  I don't want deploys to drop any objects in the target database (eg. temporary objects).  However, IgnoreAdditional  is incompatible with filter file: SQLCompare.exe terminated with the exit code 8: Unsatisfied argument dependency. But filter file is included in RG  source control and in build artifact and then used by New-DatabaseReleaseArtifact.  Is there a way to exclude filter file from build? Otherwise, I'll delete it from nuget package. 

I also have some cases for New-DatabaseReleaseArtifact using both -IgnoreAdditional and -Filterpath eg.: I have a database where some partition schemes and functions are altered dynamically and I don't want to deploy them from source control. However they have to be included in source control, otherwise the build would fail (dependencies). Using  FilterPath solves that but is incompatible with IgnoreAdditional. Any ideas for a workaround?

Kendra_Little

Hi JTR,

Is it possible for you to put the temporary objects into their own schema, and to have your filter file ignore that schema?

I've used this approach in the past for objects like that which needed to be in the database itself rather than tempdb, due to needing to persist through a restart, etc. Putting them in their own schema helped make it clear that they didn't need to be checked into source and also made it easy for operations folks to identify, plus it simplified our cleanup scripts should some of them be orphaned.

I am personally more of a fan of filter files than I am of -IgnoreAdditional, just because you're explicitly saying where you don't mind drift with a filter file pattern, and -IgnoreAdditional could allow unintendend drift to creep in.

Kendra

JTR

Hi, thanks for reply.  I like the idea of a separate schema, however, it would demand quite a lot of changes in our case - a data warehouse project with lots of 'temporary' tables during ETL. And more discipline from developers:). I'll consider it as a  long term goal.

Kendra_Little

No problem, and makes sense.

For excluding filter file from build, it would help to know the exact combo of tools that you are using so that I can set up a repro. Are you using SQL Source Control for the state first version-control tie in, and then using SCA to deploy? Or are you using SQL Change Automation for the whole thing (migrations first approach to version control)?

My memory of testing this was actually that you had to specify the filter path on the build to use a filter file at all (and that it didn't carry through filters set up in source control), but it may be that I'm mis-remembering or was using a different product combo than you are, so I'd like to re-check real fast with your setup.