No, the job_run_id field is not populated only when dbt Cloud jobs are run. Elementary can collect job metadata—including job_run_id—from any orchestrator, not just dbt Cloud. For dbt Cloud, job_run_id is automatically populated using the DBT_CLOUD_RUN_ID environment variable. However, when using dbt Core (or other orchestrators), you can manually populate job_run_id by setting the appropriate environment variable (e.g., DBT_JOB_RUN_ID) or by passing it as a dbt var in your invocation. For example:

shell dbt run --vars '{"job_run_id": "your_run_id_here"}'

or

shell DBT_JOB_RUN_ID=your_run_id_here dbt run

This approach is supported for any orchestrator, as long as you configure the environment variables or dbt vars accordingly. So, job_run_id can be populated for dbt Core jobs as well, but it is not automatic—you need to set it up yourself. In dbt Cloud, some fields like job_run_id are set by default, while in dbt Core you must provide them explicitly if you want them populated in the dbt_invocations table [Collect jobs info from orchestrator](https://docs.elementary-data.com/oss/guides/collect-job-data) [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1675247192078489).

You are correct: the job_run_id should be unique for each run of a job, not a static value. In orchestrators like dbt Cloud, this is handled automatically—each job run gets a unique job_run_id via the DBT_CLOUD_RUN_ID environment variable. When using dbt Core or other orchestrators, you need to ensure that the value you pass for job_run_id (either as an environment variable or as a dbt var) is unique for each run. If you pass a static value, all runs will have the same job_run_id, which defeats the purpose of tracking individual job executions. The documentation and community discussions confirm that you should set these values dynamically, typically by using environment variables provided by your orchestrator (such as Jenkins' BUILD_NUMBER, Airflow's run id, etc.) or by scripting your dbt invocation to inject a unique value for each run [Collect jobs info from orchestrator](https://docs.elementary-data.com/oss/guides/collect-job-data) [Slack Jenkins example](https://slack.com/archives/C02CTC89LAX/p1693381415910399). So, to properly track each job run, you must pass a unique job_run_id for every invocation.

I'm sorry, but the knowledge sources do not contain specific information or examples about integrating Elementary with GCP Workflows or how to structure the dbt command for passing job metadata from GCP Workflows. The documentation and community discussions provide examples for dbt Cloud, Airflow, Jenkins, and other orchestrators, but GCP Workflows is not explicitly mentioned. If GCP Workflows exposes job/run metadata as environment variables, you could follow the general pattern used for other orchestrators by passing those values as environment variables or dbt vars, for example:

shell dbt run --vars '{"orchestrator": "gcp_workflows", "job_name": "<your_job_name>", "job_run_id": "<your_unique_run_id>"}'

However, you will need to adapt this to how GCP Workflows exposes its metadata, which is not detailed in the provided sources. If you need more specific guidance, you may want to consult the GCP Workflows documentation or open an issue with the Elementary team as suggested in their documentation [Collect jobs info from orchestrator](https://docs.elementary-data.com/oss/guides/collect-job-data).

If your dbt_tests table is empty, there are a few common causes and troubleshooting steps you can follow: 1. No Tests Have Been Run: Make sure you have actually added and executed tests in your dbt project. If you run

dbt test

without any tests defined, or if you haven't added tests to your models, the dbt_tests table will remain empty. This is a common issue for new users [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1706612460738369). 2. Target/Schema Mismatch: Ensure that you are running both

dbt run --select elementary

and

dbt test

on the same target and schema. If the elementary tables are created in one target/schema and tests are run in another, the results will not be written to the expected tables [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1683764076675589). 3. Materialization Issues: The elementary tables, including dbt_tests, must be materialized as tables (not views). If there is a materialization override in your

dbt_project.yml

that causes these to be created as views, no data will be inserted. Check your configuration and ensure the correct materialization [Elementary troubleshooting guide](https://docs.elementary-data.com/oss/general/troubleshooting). 4. Configuration Disables Results Upload: If you have set variables like

disable_tests_results: true

in your dbt configuration, the dbt_tests table will not be populated. Make sure these are not set unless intentionally disabling results upload [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1699310045488249). 5. On-Run-End Hook Not Executing: Elementary uses an on-run-end hook to upload test results. If this hook is not running (for example, due to a failure in a previous hook or a misconfiguration), the dbt_tests table will remain empty. Check your dbt logs for any errors related to hooks [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1722936228529189). If you have checked all of the above and the table is still empty, review your dbt and Elementary versions for compatibility, and consider reaching out to the Elementary support team with your logs for further assistance [Elementary troubleshooting guide](https://docs.elementary-data.com/oss/general/troubleshooting).

The behavior you're describing—where the dbt_tests table becomes populated after running

dbt run --select elementary

, but is empty after a subsequent `dbt run`—is likely due to how the dbt_tests table is materialized and refreshed. According to the knowledge sources, the dbt_tests table is a metadata table (not incremental), and Elementary does a

create or replace

on these tables. This means that every time you run the model (e.g., with

dbt run --select elementary

), the table is recreated and populated with the current state of your dbt project's tests. However, if you run a general

dbt run

that does not include the elementary models, the dbt_tests table will not be updated, and depending on your project setup, it could be dropped or left empty if the schema is refreshed or cleaned as part of your pipeline [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1673625954189599). If the dbt_tests table is empty, this can indeed be the reason why tests do not appear in the invocation results or in your reports, since Elementary relies on this table to display test metadata and results [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1662059505282089). To ensure the dbt_tests table is always populated: - Always run

dbt run --select elementary

after changes to your tests or models. - Make sure your pipeline does not drop or clean the schema containing the elementary tables between runs. - Confirm that your dbt_project.yml and materialization configs are not overriding the expected behavior. If you continue to see the table emptied unexpectedly, review your pipeline for any steps that might be recreating or cleaning schemas, and ensure the elementary models are included as needed [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1673625954189599).

To correct the issue where the dbt_tests table is empty after running a general

dbt run

, but is populated after

dbt run --select elementary

, you should ensure the following: 1. Always Run Elementary Models When Needed: The dbt_tests table is created and populated by running the Elementary models. This is typically done with

dbt run --select elementary

. If you only run

dbt run

without including the elementary models, the dbt_tests table will not be updated. Therefore, after making changes to your tests or models, or after a schema refresh, you should run:

dbt run --select elementary

This ensures the dbt_tests table is recreated and populated with the latest test metadata [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1673625954189599). 2. Avoid Schema Drops or Cleanups: If your pipeline drops or cleans the schema containing the elementary tables between runs, the dbt_tests table (and others) will be lost. Make sure your pipeline does not remove these tables unless you intend to fully refresh them and immediately repopulate with

dbt run --select elementary

. 3. Check Materialization Configurations: Ensure there are no materialization overrides in your

dbt_project.yml

that could cause the dbt_tests table to be created as a view or otherwise interfere with its expected behavior. The table should be materialized as a table, not a view [Elementary troubleshooting guide](https://docs.elementary-data.com/oss/general/troubleshooting). 4. Include Elementary Models in Your Pipeline as Needed: You do not need to run the elementary models on every pipeline run, but you should run them after any changes to your dbt project structure or tests, or after a schema refresh. This will keep the dbt_tests table up to date and ensure test metadata appears in invocation results and reports [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1662059505282089). If you follow these steps and still encounter issues, review your pipeline for any steps that might be unintentionally removing or altering the elementary tables, and ensure you are running the correct commands on the correct target and schema. If the problem persists, consider reaching out to Elementary support with your logs for further troubleshooting.

No, it is not expected for the

dbt_tests

table to be empty after execution if you have tests defined in your dbt project and have run the appropriate commands. The

dbt_tests

table is designed to store metadata about all the tests in your project and is populated when you run the Elementary models (typically with

dbt run --select elementary

). Each time this model is executed, the data is replaced with the current state of your project's tests [dbt package models - dbt_tests](https://docs.elementary-data.com/dbt/package-models#dbt-artifacts). If the table is empty after execution, it usually indicates one of the following: - No tests are defined in your project. - The Elementary models were not run (i.e., you did not execute

dbt run --select elementary

). - There is a configuration or materialization issue preventing the table from being populated. - The schema or table was dropped or cleaned between runs. If you have tests defined and have run the Elementary models, the table should not be empty. If it is, further investigation into your pipeline and configuration is needed [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1673625954189599).