I’m doing some local testing using dbt core and trying to figure out how to only rerun models associated with failed tests from the prior dbt build invocation.
I’ve setup a test scenario with 3 models (models a, b, and c). I ran dbt build. The models were built and tests were run. The scenario has a failed not_null test, which impacts models a and c.
Now, I want to rerun only the models associated with the failed test (a and c), without having to manually select them.
I tried doing dbt build --select 1+result:fail which I found here. That resulted in
Encountered an error:
No comparison run_results
I also tried dbt build –-select result:error+ –-defer -–state ./target which I found here. That resulted in
dbt: error: unrecognized arguments: –-select result:error+ –-defer -–state ./target
I’m guessing running only models impacted by failed tests relies on run_results.json which I see in ./target. So, I'm thinking I’m missing some kind of configuration step, but I’m having a hard time finding info on how to rerun dbt from the point of failure. Any suggestions or resources for this issue?
Ok, I ended up having some unnoticed em dashes in the second command I tried.
This is what I was after
dbt build --select 1+result:fail+ --defer --state ./target
Answered in dbt slack.
Related
I have a dbt project with several singular tests that ref() several models, many of them testing if a downstream model matches some expected data in the upstream. Whenever I build only another downstream model that uses the same upstream models, dbt will try to execute the tests with an out-of-date model. Sample visualization:
Model "a" is an upstream view that only makes simply transformations on a source table
Model "x" is a downstream reporting table that uses ref("a")
Model "y" is another downstream reporting table that also uses ref("a")
There is a test "t1" making sure every a.some_id exists in x.some_key
Now if I run dbt build -s +y, "t1" will be picked up an executed, however "x" is out-of-date when compared to "a" since new data has been pushed into the source table, so the test will fail
If I run dbt build -s +y --indirect-selection=cautious the problem will not happen, since "t1" will not be picked up in the graph.
I want every single dbt command in my project to use --indirect-selection=cautious by default. Looking at the documentation I've been unable to find any sort of environment variable or YML key in dbt_project that I could use to change this behavior. Setting a new default selector also doesn't help because it is overriden by the usage of the -s flag. Setting some form of alias does work but only affects me, and not other developers.
Can I make every dbt build in my project use cautious selection by default, unless the flag --indirect-selection=eager is given?
I am using dbt version 0.19.1.
I have a pipeline that automatically runs dbt docs generate whenever i push some changes to my git repository.
From a certain point in time, pipelines started to fail with these error message:
Running with dbt=0.19.1
Found 776 models, 0 tests, 0 snapshots, 0 analyses, 359 macros, 0 operations, 0 seed files, 145 sources, 0 exposures
14:44:45 | Concurrency: 8 threads (target='default')
14:44:45 |
14:45:07 | Done.
14:45:07 | Building catalog
Encountered an error while generating catalog: 'dtype'
dbt encountered 1 failure while writing the catalog
The problem is that I have many models and changes happening in the source code and it is not easy to understand from this message where the error is coming from.
If I check the logs files in the logs folder they are very messy, containing debug information from all the threads, i cannot find the source of the issue.
Is there a way to understand where this issue is coming from?
Is it possible to better debug dbt docs generate command?
Thank you all for your replies in advance!
Francesco
Is it possible to better debug dbt docs generate command?
To better debug the issue you can use
dbt --debug docs generate
That will contain the debug information from all the threads, but it should also include a stack trace from where the error was raised.
Thank you Josh, adding another point to look for the error.
I suggest who have the same issues and has thousands of rows of logs like me to look for the string "Error while running" in the debug logs to find the place where the exception should have raised.
Hopes this could help someone else.
I divide this to two issues , but solving any one of them will solve the other.
Issue 1:
When I use the section at the bottom of the following picture and add "configurations to release", the build is not triggering release management.
I queried the build logs for hours, and saw that it stops the release when it founds out that the configuration "does not match current"
If ConfigurationsToRelease Matches Current
Initial Property Values
Condition = False
Final Property Values
Condition = False
Final Property Values
Condition = True
before more words, I will show a picture that sums it up:
the build definition and ms build logs
in a default case, where configuration to release is blank , release management would continue from this point and write in the logs "Release the build" (as a command that happened) and the build would trigger release management.
If you look at my tfs build configurations, you can see it's exactly the same as the upper regular ms build configurations , but still I get this error of a mismatch.
In any case I only have only one dialog to fill my configurations at in build definition as shown in the 'configuration dialog' in the above pic.
I succeeded to release once or twice this way in this same project the other day by adding release configurations, it somehow worked, but then stopped working (worked once or twice as a glitch I think like something is cached there) but 99% of the other attempts failed, it was always stopping my trigger from tfs to release since the first time I tried it a few months ago.
Has someone here experienced it? I looked in a lot of places and spotted only one guy that complained about it. His solution was to remove it (not exactly a solution)
Is there a build argument that can fix this? (/p:something=something)
Issue 2: if anyone can solve it in a way different than rm configurations , then I don't need issue 1 to be solved.
For any one who is interested why I even messed with release configuration section of build definition, it's because I want rm to wait for all transformations to happen before rm intervention, and this seems like a way to tell rm , ok dude , see there? you got 2 configurations to wait for their build.
The thing is that by default when that configuration section is blank, rm is getting in the way of tfs build and tfs build is getting in the way of rm, something like a circular wait. rm expects both transformed folders to exist in build outputs when tfs build is waiting for rm to finish it's run after the first build, tfs wants to continue building the second configuration (and transform) but rm is involved already , seeking for it's second configuration, breaking the build when fails to find it, hence the second configuration will never be created, while rm is still waiting for it and tfs build waits for rm and build breaks. confusing? read again and see the pic below cause it's interesting enough.
more info for clarity:
the next stage of RM is trying to get something from build outputs folder before it's already there.
for example , if i set Release build to true , it will only build the first configuration (a folder is created, picture below) , rm will succeed in first step (QA.Release), and continue strait to try and grab Release for its next stage, but it's not built yet by TFS Build , which waits for rm to finish it's weird intervention in the middle of tfs's build work . and like i said above, I'm sure I've seen it work once or twice in one of my attempted builds.
the tfs output folder whith release build flag on(only one transform happens) \ when off (all two transforms work) + rm error when on (circular wait)
If I understand your situation correctly I think your problem is that you are building multiple configurations. This breaks one of the core tenets of continuous delivery which is that for a given release you should build only once and deploy that same build to each stage in your pipeline, in sequence.
In order to do this your build needs to be stage agnostic, which in practice means all your configuration (eg database connection string) needs to be tokensised so that the correct value can be swapped in for the particular stage (QA, Release etc). I have a blog post series here that explains the full process (for a sample web application) in great detail.
i managed to solve issue 2 , and by doing so, issue 1 is no longer relevant .
i switched to ReleaseTfvcTemplate.12.xaml as a build template (found on your C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin)
and then the build finished all configurations before RM intervention .
truly seems like a bug in ReleaseDefaultTemplate.11.1.xaml , or this might be because i was using some additional msbuild arguments (which were needed) , or the fact i'm using slow cheetah to create transforms on a windows service (transformations are only introduced in web applications).
either way , i'm now able to perform advanced tasks , like using the transforms to add \ remove tags that should be different in production , for example , i can leave the use of diagnostics in the configuration file for qa use , and remove it for production to make the verbosity lower there . still am using RM PlaceHolders technique in conjunction to transformation technology , to enjoy both worlds where it comes to changes related to environments , but still keeping the principles by passing the same build (dlls) through all environments .
I have a multi module Gradle script with 3 modules: common, services and web.
If I run gradle check all the test suite is performed correctly, but I don't have a single test report instead I found a test report for each subproject. How can I merge the test results?
If useful this is the script I'm using https://github.com/CarloMicieli/trenako/blob/master/build.gradle
Thanks
Carlo
The Gradle source contains a Task class used to accomplish this, which unfortunately isn't available in the public API. Basically all it does is copy all of the test reports from various projects into one directory and then run the standard test report task to get an aggregate. Check out the source code at https://github.com/gradle/gradle/blob/master/buildSrc/src/main/groovy/org/gradle/build/TestReportAggregator.groovy
Sometimes the hudson build step fails and does not execute all my tests, which really screws up the test trend graph because it shows a 50% drop in the number of tests and then goes up again. Is there a way to exclude the failed builds? I tried to delete the whole failed build but that didn't help.
If you delete the "offending" build and then run another build I think you'll find the trend graph is rebuilt without the blip.
That said, I have to side with #DarkDust on this one. If your CI environment is prone to wobble then these stats can be useful for diagnostics.