@kapa.ai Hello ! From time to time, we have data quality tests that are failing but that we can't tackle ourselves, it's an upstream issue that we're not responsible for. The annoying thing is that the elementary tests keep failing though. It's good that it fails, but it's annoying that we can't do anything to fix the test while the test keeps failing. I don't want to delete the test, i want to avoid making a filter on the test also because then we would add exceptions onto exceptions in a never ending cycle. What would you recommend ? Is there a mechanism in Elementary to handle this ?

Hey @Adonis HARROUK! Searching the Elementary knowledge base, normally takes around 15 seconds 😊 Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai

@kapa.ai Ah suppression intervals are nice ! It's not a perfect solution, i think i would have liked something where we can say that the test is "resolved" and then it never fails for that reason again until some time and is hidden in the dashboard. But for now i'll use that atleast to hide the errors on the alerts and keep it on the dashboard. Do you think putting a week is too long in terms of delay ?

Let me check the knowledge base for you again. One moment! 📚

@kapa.ai explain about the GitHub Actions integration

Elementary GitHub Actions Integration Elementary provides a GitHub Actions integration that lets you run

edr

commands in an automated way — for example, sending data observability reports, monitoring for data issues, and sending alerts to Slack. [GitHub Actions docs] The Official Action Elementary publishes a ready-made action:

elementary-data/run-elementary-action

. You reference it in your workflow like this:

- name: Run Elementary
  uses: elementary-data/run-elementary-action@v1.12
  with:
    warehouse-type: snowflake  # or bigquery, redshift, etc.
    adapter-version: 1.5.0     # optional, defaults to latest
    profiles-yml: ${{ secrets.ELEMENTARY_PROFILES_YML }}
    edr-command:
      edr monitor
        --slack-token "${{ secrets.SLACK_TOKEN }}"
        --slack-channel-name "${{ secrets.SLACK_CHANNEL_NAME }}"
      &&
      edr report
        --file-path "report.html"
      &&
      edr send-report
        --slack-token "${{ secrets.SLACK_TOKEN }}"
        --slack-channel-name "${{ secrets.SLACK_CHANNEL_NAME }}"
        --s3-bucket-name "${{ secrets.S3_BUCKET_NAME }}"

Key Requirements 1.

profiles.yml

with an

elementary

profile — typically stored as a GitHub secret (

ELEMENTARY_PROFILES_YML

). You can generate it with:

dbt run-operation --args '{"method": "github-actions"}' elementary.generate_elementary_cli_profile

2. Warehouse type — must be specified (

bigquery

,

snowflake

,

redshift

, etc.). 3. Adapter version — should match your dbt adapter version for compatibility. [Adapter version fix] 4. Cloud credentials — for BigQuery, GCS, or S3, pass keyfiles/credentials as secrets. Common

edr

Commands Used •

edr monitor

— reads test results and sends alerts for failures •

edr report

— generates the Elementary UI report locally •

edr send-report

— generates and sends the report to Slack, S3, or GCS Note:

edr send-report

also generates a report internally, so running

edr report

before it is not strictly necessary. Common Pitfalls • Organization restrictions on private repos: External actions may be blocked by default. A workaround is to fork the

run-elementary-action

into your own organization. [Private repo restriction] • Keyfile paths: Always use absolute paths (e.g.,

/tmp/dbt-service-account.json

) for keyfiles, not relative paths, as

edr

may run from a different directory. [Absolute path fix] • Environment variables in profiles.yml: Make sure they are exposed as

env:

in the workflow step so they can be resolved. [Env vars approach] • dbt must run before Elementary: The action only runs

edr

commands. If you need

dbt run

or

dbt test

to happen first, add those as separate prior steps. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai local testing for integration

The knowledge sources provided don't contain enough information to give a confident answer about local testing for the GitHub Actions integration specifically (e.g., using tools like

<https://github.com/nektos/act|act>

). What I can share from the knowledge sources is that one community member did attempt to test the Elementary GitHub Action locally using

act

(a tool for running GitHub Actions locally), and encountered this error:

Failed to get Elementary dbt package version: ...
'str' object has no attribute 'get'

This was related to how the

profiles.yml

was being passed and resolved in the local environment. [Local act testing] Beyond that specific mention, the knowledge sources don't provide detailed guidance on local testing workflows for the Elementary GitHub Actions integration. I'd recommend checking the Elementary GitHub Actions repository directly or reaching out in the Elementary Slack community for more specific guidance on this topic. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Hello, going back to the topic of the suppression interval, please forget your other discussions. I tried it and it correctly muted the alerts sent to Slack. However, i'm still not fully satisfied because the elementary summary report still shows the errors, i was kind of hoping it would not. Else i'm also looking for a way to potentially disable the test for a set period of time if it fails because it makes our airflow DAG fail also which triggers another alert on our side. Or if you have any other ideas, please tell me.

Good to hear the suppression interval is working for Slack alerts! Let me address your two points: 1. Suppression Interval & the Elementary Report The suppression interval only affects alert sending (Slack/Teams notifications) — it does not hide or suppress failures from the Elementary dashboard/report. The report will continue to show the test failures regardless of the suppression interval configuration. [Suppression interval docs] If you want to hide the test from the dashboard entirely (without deleting it), the option mentioned previously is to set

enabled: false

in the test config. This will stop Elementary from collecting results for that test and it will disappear from the report. However, this also means it won't run at all, which brings us to your second point. 2. Disabling the Test for a Set Period The knowledge sources do not describe a built-in mechanism to temporarily disable a dbt test for a fixed time window and then automatically re-enable it. There is no "snooze until date X" feature in Elementary OSS. What the community has discussed as the closest alternatives are: • Suppression interval — already using this ✅ • Manually setting

enabled: false

on the test when the upstream issue is known, and re-enabling it once resolved — but this requires a manual code change and dbt run each time [Disable test] • A proper "mark as resolved/acknowledged" mechanism has been raised as a feature request by the community but is not yet implemented [Feature request] Regarding the Airflow DAG Failure If the dbt test failure is causing your Airflow DAG to fail, that's a dbt-level behavior (test severity), not something Elementary controls directly. One approach mentioned in the knowledge sources is to set the test severity to

warn

instead of

error

in dbt — this way the test still runs and Elementary still captures the result, but it won't cause the dbt invocation to fail:

tests:
  +severity: warn

This would prevent the Airflow DAG from failing while still keeping the test active and visible in Elementary. [Severity warn] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.