docs: PR/MR data quality review feature page

[joostboon]

Summary

• Replaces the old closed-beta CI placeholder with a full feature page
• Sells the feature with value prop, then flows into setup
• Covers GitHub Actions (2 steps) and GitLab CI (2 steps)
• Includes configuration options, troubleshooting section

Preview

https://docs.elementary-data.com/cloud/features/ci

🤖 Generated with Claude Code

Summary by CodeRabbit

• Documentation
  • Added comprehensive PR/MR Data Quality Review docs describing automated data-quality context in pull requests and merge requests.
  • Provided end-to-end setup and usage instructions for GitHub Actions and GitLab CI, including required secrets, workflow snippets, and optional customization.
  • Expanded “How it works” and troubleshooting guidance, plus notes on sync behavior and common integration issues.

[github-actions]

👋 @joostboon
Thank you for raising your pull request.
Please make sure to add tests and document all user-facing changes.
You can do this by editing the docs files in this pull request.

[coderabbitai]

📝 Walkthrough

Walkthrough

New and revised documentation for the PR / MR Data Quality Review feature: adds a cloud-specific guide and replaces the previous CI doc with an end-to-end walkthrough covering how the review is produced, prerequisites, GitHub Actions and GitLab CI setup examples, required secrets/variables, and troubleshooting. (49 words)

Changes

Cohort / File(s)	Summary
PR/MR Data Quality Review docs docs/cloud/features/ci.mdx, docs/features/ci.mdx	Added a new cloud-specific doc and replaced the existing CI page with a full PR/MR Data Quality Review guide: architecture and "How it works", prerequisites (MCP server, Anthropic & Elementary API keys), GitHub Actions workflow and repo secrets, GitLab CI include snippet and variables, setup steps, troubleshooting, and model sync behavior note.

Sequence Diagram(s)

sequenceDiagram
    participant Dev as Developer
    participant Repo as Git Hosting (GitHub/GitLab)
    participant CI as CI (GitHub Actions / GitLab CI)
    participant MCP as Elementary Cloud MCP
    participant Model as LLM (Anthropic / Claude)
    participant API as Elementary API

    Dev->>Repo: Open PR / MR
    Repo->>CI: Trigger workflow (diff, tests, metadata)
    CI->>MCP: Send diff, test history, repo metadata
    MCP->>Model: Request analysis (Anthropic)
    Model-->>MCP: Return data-quality context
    MCP->>API: Fetch model/repo health & downstream impact
    API-->>MCP: Return summaries
    MCP->>CI: Provide composed PR comment content
    CI->>Repo: Post PR/MR comment with data-quality review
    Repo-->>Dev: Display comment on PR/MR

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I nibble on diffs at night,
I stitch test tales into light,
A Claude-sprung whisper, neatly spun,
PRs glow bright — the rabbit's done! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main change: documentation for a PR/MR data quality review feature, which aligns with the substantial documentation additions across two files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/ci-pr-review-docs

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (1)

docs/features/ci.mdx (1)

2-137: Consider making one CI review page canonical.

This file now mirrors docs/cloud/features/ci.mdx almost verbatim. Keeping the setup snippets and troubleshooting text in two places will make future fixes like these easy to miss; a redirect, alias, or shared MDX partial would reduce drift.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/features/ci.mdx` around lines 2 - 137, This page duplicates
docs/cloud/features/ci.mdx; make one canonical and update the other to reference
it: pick either docs/features/ci.mdx or docs/cloud/features/ci.mdx as the source
of truth, remove duplicated content from the non-canonical file (including the
title "PR / MR Data Quality Review", the GitHub Actions and GitLab CI snippets,
the Accordion block, and Troubleshooting/Warning sections), and replace it with
a short MDX redirect/alias or an import that points to the canonical document
(or a shared MDX partial/component for the repeated sections) so future edits to
the CI setup live in one place. Ensure links and frontmatter remain consistent
and that the chosen canonical file contains the full content for "PR / MR Data
Quality Review" and the setup examples.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/cloud/features/ci.mdx`:
- Around line 83-87: The docs table currently lists the default diff-filter as
`ACM`, which omits renamed files; update the `diff-filter` default to `ACMR` to
include renames, and also add a short parenthetical note in the Description
column for `diff-filter` (or an adjacent sentence) clarifying that including `R`
will capture renamed models (A=Added, C=Copied, M=Modified, R=Renamed) so
renames are not silently omitted; target the `diff-filter` table row and the
surrounding description text.
- Around line 70-79: Add a troubleshooting caveat to docs/cloud/features/ci.mdx
explaining that the setup relies on repository secrets (ANTHROPIC_API_KEY,
ELEMENTARY_API_KEY) in a pull_request workflow and that GitHub does not expose
these secrets to workflows triggered by forks or Dependabot (and GITHUB_TOKEN is
read-only in those contexts); briefly list mitigations such as asking
maintainers to run the workflow manually, using workflow_dispatch or
repository_dispatch for external contributions, or instructing contributors to
open PRs from branches in the main repo, and mention Dependabot as a special
case so external PRs don’t fail silently.
- Around line 57-60: Update the workflow permissions block to include contents:
read in addition to pull-requests: write so actions/checkout@v4 can access the
repo; locate the YAML permissions block under the job (the existing
"permissions:" with "pull-requests: write") and add "contents: read". Also
update the troubleshooting note that currently mentions pull-requests: write to
state that both pull-requests: write (for posting comments) and contents: read
(for checking out code) are required.

In `@docs/features/ci.mdx`:
- Around line 70-79: Update the sentence "Open a PR that touches a model file
and the review comment appears automatically." to add a caveat explaining that
the workflow uses the pull_request event and GitHub hides repository secrets for
PRs from forks and Dependabot; specify that the automatic comment will only
appear for PRs originating from branches within the same repository (not forks
or Dependabot PRs), and optionally add the same note to the Troubleshooting
section for visibility.
- Around line 57-60: The permissions block currently sets unlisted scopes to
none and omits repository read access required by actions/checkout@v4; add
"contents: read" to the permissions block (alongside pull-requests: write) so
checkout can run, and update the troubleshooting note referenced near line ~125
to explicitly mention adding "contents: read" as a required permission when
diagnosing job failures; locate the YAML permissions block and the
troubleshooting paragraph text to apply these updates.

---

Nitpick comments:
In `@docs/features/ci.mdx`:
- Around line 2-137: This page duplicates docs/cloud/features/ci.mdx; make one
canonical and update the other to reference it: pick either docs/features/ci.mdx
or docs/cloud/features/ci.mdx as the source of truth, remove duplicated content
from the non-canonical file (including the title "PR / MR Data Quality Review",
the GitHub Actions and GitLab CI snippets, the Accordion block, and
Troubleshooting/Warning sections), and replace it with a short MDX
redirect/alias or an import that points to the canonical document (or a shared
MDX partial/component for the repeated sections) so future edits to the CI setup
live in one place. Ensure links and frontmatter remain consistent and that the
chosen canonical file contains the full content for "PR / MR Data Quality
Review" and the setup examples.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0b4b9c18-4c56-4ab5-9785-5db6aa1135c4

📥 Commits

Reviewing files that changed from the base of the PR and between 2f98ef7 and 593c561.

📒 Files selected for processing (2)

• docs/cloud/features/ci.mdx
• docs/features/ci.mdx

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

GitHub Actions repository secrets pull_request workflow forked repos Dependabot

💡 Result:

• pull_request from a fork: GitHub Actions does not provide repository/organization secrets to workflows triggered by PRs opened from forked repositories, and the GITHUB_TOKEN is read-only (to prevent secret exfiltration). [1]
• Dependabot PRs are treated like forks: Workflows triggered by Dependabot on events like push / pull_request are treated as if they came from a fork, so they get a read-only GITHUB_TOKEN and no normal Actions secrets. [1]
• Use “Dependabot secrets” for Dependabot-triggered runs: If Dependabot needs credentials (e.g., registry tokens), store them under Repo → Settings → Security → Dependabot → Secrets (or org-level Dependabot secrets). Those are the secrets intended for workflows initiated by Dependabot. [2][3][4]
• pull_request_target is risky (and doesn’t “fix” Dependabot secret access): pull_request_target runs in the base repo context and can expose secrets if you check out / execute untrusted PR code; GitHub explicitly warns about this trigger. Also, for Dependabot, even pull_request_target runs still have read-only token and no secrets in the Dependabot-PR case. [5][3]
• Common workaround pattern: Keep PR checks that don’t need secrets on pull_request, and run any secret-requiring steps in a separate, gated workflow (often via workflow_run) or by using Dependabot secrets with the same secret names your workflow expects. [1]

Sources:
[1] GitHub Docs – Troubleshooting Dependabot on GitHub Actions
[2] GitHub Docs – Automating Dependabot with GitHub Actions
[3] GitHub Docs – Dependabot on GitHub Actions
[4] GitHub Docs – Configuring access to private registries for Dependabot
[5] GitHub Docs – Using GitHub’s security features to secure your use of GitHub Actions

---

🏁 Script executed:

# Check if the file exists and review the content around lines 70-79
fd "ci.mdx" docs/

Repository: elementary-data/elementary

Length of output: 169

---

🏁 Script executed:

# Read the file to see the context around lines 70-79
sed -n '60,90p' docs/cloud/features/ci.mdx

Repository: elementary-data/elementary

Length of output: 1114

---

🏁 Script executed:

# Check the full structure of the file to see if there's a troubleshooting section
cat -n docs/cloud/features/ci.mdx | head -150

Repository: elementary-data/elementary

Length of output: 5743

---

Add a fork/Dependabot caveat in the Troubleshooting section.

The setup depends on repository secrets inside a pull_request workflow, but GitHub does not pass those secrets to PRs from forked repositories or Dependabot, and the GITHUB_TOKEN is read-only in those contexts. External contributors and Dependabot runs will encounter a broken setup without this caveat.

Suggested addition to Troubleshooting

**The comment says the MCP server is unreachable**

Verify `ELEMENTARY_API_KEY` is correctly set and the MCP server is enabled for your account. See the [MCP setup guide](/cloud/mcp/setup-guide).

+**Setup doesn't work for forks or Dependabot PRs**
+
+<Warning>
+This workflow works for pull requests opened from branches in the same repository. GitHub does not pass repository secrets to `pull_request` workflows from forks or Dependabot PRs.
+</Warning>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` around lines 70 - 79, Add a troubleshooting
caveat to docs/cloud/features/ci.mdx explaining that the setup relies on
repository secrets (ANTHROPIC_API_KEY, ELEMENTARY_API_KEY) in a pull_request
workflow and that GitHub does not expose these secrets to workflows triggered by
forks or Dependabot (and GITHUB_TOKEN is read-only in those contexts); briefly
list mitigations such as asking maintainers to run the workflow manually, using
workflow_dispatch or repository_dispatch for external contributions, or
instructing contributors to open PRs from branches in the main repo, and mention
Dependabot as a special case so external PRs don’t fail silently.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -name "ci.mdx" -type f | head -20

Repository: elementary-data/elementary

Length of output: 121

---

🏁 Script executed:

wc -l docs/features/ci.mdx 2>/dev/null || echo "File not found"

Repository: elementary-data/elementary

Length of output: 94

---

🏁 Script executed:

sed -n '50,80p' docs/features/ci.mdx 2>/dev/null || echo "File not found"

Repository: elementary-data/elementary

Length of output: 865

---

🏁 Script executed:

sed -n '120,130p' docs/features/ci.mdx 2>/dev/null || echo "File not found"

Repository: elementary-data/elementary

Length of output: 433

---

🌐 Web query:

GitHub Actions permissions workflow scope behavior explicit permissions block

💡 Result:

• permissions: controls the GITHUB_TOKEN scopes for each job in a workflow, and can be set:

  • Top-level (permissions:) → becomes the default for all jobs in that workflow.
  • Per-job (jobs.<job_id>.permissions:) → overrides the workflow-level setting for that specific job. [1]

• How the effective permissions are calculated (order matters):

  1. Start from the enterprise/org/repo default “Workflow permissions” setting for GITHUB_TOKEN.
  2. Apply any workflow-level permissions: in the YAML.
  3. Apply any job-level permissions: in the YAML.
  4. If triggered by a fork PR and “Send write tokens to workflows from pull requests” is not enabled, any write permissions are downgraded to read. [1]

• Key “gotcha” with an explicit permissions block:
  If you set any permission explicitly, then any permission not listed is set to none (so adding a small permissions: block can unintentionally remove other scopes you were relying on). [1]

• Useful shorthands:

  • permissions: read-all
  • permissions: write-all
  • permissions: {} (disable all) [1]

• Recommended practice: set the repo/org default to least privilege (often read-only) and then grant only what a given job needs. [2]

Sources: GitHub Actions workflow syntax (permissions + calculation order) [1], GitHub security hardening guidance [2].

---

🌐 Web query:

actions/checkout requires contents read permission GitHub Actions

💡 Result:

actions/checkout uses the job’s GITHUB_TOKEN to fetch (read) your repository, so the token must have contents: read permission (unless you provide a different auth via the action’s token or ssh-key inputs). [1]

Add this at the workflow or job level:

permissions:
  contents: read

steps:
  - uses: actions/checkout@v4

If you’ve locked permissions down (anything not listed becomes none), explicitly granting contents: read is required. [2]

Also check the repo/org setting Settings → Actions → General → Workflow permissions (restricted mode gives GITHUB_TOKEN read access to contents and packages; permissive mode is read/write for more scopes). [3]

Sources: [1] [2] [3]

---

Add contents: read to the job permissions.

Line 57 introduces an explicit permissions block, which sets any unlisted scope to none. This removes the repository-read access that actions/checkout@v4 requires, causing the job to fail before the Elementary step runs. Update the troubleshooting note (around line 125) to mention contents: read as well, since it's equally critical.

🛠️ Proposed fix

     permissions:
+      contents: read
       pull-requests: write

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	permissions:
	pull-requests: write
	steps:
	- uses: actions/checkout@v4
	permissions:
	contents: read
	pull-requests: write
	steps:
	- uses: actions/checkout@v4

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/features/ci.mdx` around lines 57 - 60, The permissions block currently
sets unlisted scopes to none and omits repository read access required by
actions/checkout@v4; add "contents: read" to the permissions block (alongside
pull-requests: write) so checkout can run, and update the troubleshooting note
referenced near line ~125 to explicitly mention adding "contents: read" as a
required permission when diagnosing job failures; locate the YAML permissions
block and the troubleshooting paragraph text to apply these updates.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's find and inspect the file mentioned
fd "ci.mdx" -t f

Repository: elementary-data/elementary

Length of output: 169

---

🌐 Web query:

GitHub Actions secrets behavior with forked pull requests and Dependabot

💡 Result:

Forked pull requests (pull_request)

• Workflows triggered by pull_request from forks run with no repository secrets (except the auto-minted GITHUB_TOKEN) and that GITHUB_TOKEN is read-only/minimal privileges. This is a deliberate security guarantee to prevent exfiltration of secrets by untrusted PR code. [1]

pull_request_target (often used to intentionally access secrets on PRs)

• pull_request_target runs in the context of the base repository, so it can access repository secrets, including when the PR comes from a fork—this is powerful but risky if you check out / run untrusted PR code. [2]
• GitHub also updated pull_request_target so the workflow file/checkout reference comes from the repo’s default branch, but it remains higher-risk specifically because it executes with access to secrets for fork PRs. [3]

Dependabot-triggered workflows and secrets

• If a workflow is triggered by Dependabot, GitHub supports Dependabot secrets (configured separately from Actions secrets) and they appear in the workflow via the normal secrets.* context. A common pattern is to create both an Actions secret and a Dependabot secret with the same name, so the workflow works for both Dependabot and humans. [4]
• Special restriction: for workflows initiated by Dependabot using pull_request_target, if the PR/base ref was created by Dependabot, then secrets are not available and the GITHUB_TOKEN is read-only. [5]
• Additionally, some event types triggered by Dependabot are hard-limited to read-only token and no secrets (per GitHub’s changelog). [6]

Practical takeaway

• Use pull_request for CI that runs PR code (safe-by-default: no secrets). [1]
• If you need secrets for PR-related automation (labeling/commenting, etc.), use pull_request_target but avoid executing untrusted PR code; otherwise you risk secret exfiltration. [2][3]
• For Dependabot, prefer Dependabot secrets (or dual secrets with same name) and expect stricter limits, especially with pull_request_target. [4][5]

Sources: [1] GitHub Security blog guidance on fork PR privilege limits; [2] GitHub changelog/discussion on pull_request_target secret exposure risk; [3] GitHub changelog (Nov 7, 2025) on pull_request_target behavior; [4] GitHub Docs: Troubleshooting Dependabot on GitHub Actions; [5] GitHub Docs: Dependabot on GitHub Actions; [6] GitHub Changelog (Dec 9, 2021) Dependabot-triggered workflow permission changes.

---

🏁 Script executed:

# Let's inspect the file to see the actual content and check the workflow event trigger
head -120 docs/features/ci.mdx | tail -60

Repository: elementary-data/elementary

Length of output: 1942

---

🏁 Script executed:

# Also check the entire file to understand context and find troubleshooting section
wc -l docs/features/ci.mdx

Repository: elementary-data/elementary

Length of output: 94

---

🏁 Script executed:

# Let's get the exact lines 70-79 that the review comment references
sed -n '70,79p' docs/features/ci.mdx

Repository: elementary-data/elementary

Length of output: 408

---

🏁 Script executed:

# Also check a wider range to understand the workflow trigger and look for troubleshooting section
sed -n '1,80p' docs/features/ci.mdx

Repository: elementary-data/elementary

Length of output: 2734

---

🏁 Script executed:

# Check the rest of the file to see if there's a troubleshooting section
sed -n '80,137p' docs/features/ci.mdx

Repository: elementary-data/elementary

Length of output: 2122

---

Add a fork/Dependabot caveat before promising automatic comments.

The workflow shown uses pull_request events, where GitHub deliberately withholds repository secrets from forked and Dependabot PRs as a security measure. The current text "Open a PR that touches a model file and the review comment appears automatically" will fail silently for external contributors without this critical context. Add a note either immediately after that line or in the Troubleshooting section clarifying that this workflow requires the PR to originate from a branch in the same repository, not from a fork or Dependabot.

🛠️ Suggested note

 That's it. Open a PR that touches a model file and the review comment appears automatically.
+
+<Warning>
+This workflow works for pull requests opened from branches in the same repository. GitHub does not pass repository secrets to `pull_request` workflows from forks or Dependabot PRs.
+</Warning>

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	**Step 2 — Add two repository secrets**
	Go to **Settings > Secrets and variables > Actions** and add:
	| Secret | Description |
	|---|---|
	| `ANTHROPIC_API_KEY` | Your Anthropic API key |
	| `ELEMENTARY_API_KEY` | Your Elementary Cloud API key |
	That's it. Open a PR that touches a model file and the review comment appears automatically.
	**Step 2 — Add two repository secrets**
	Go to **Settings > Secrets and variables > Actions** and add:
	| Secret | Description |
	|---|---|
	| `ANTHROPIC_API_KEY` | Your Anthropic API key |
	| `ELEMENTARY_API_KEY` | Your Elementary Cloud API key |
	That's it. Open a PR that touches a model file and the review comment appears automatically.
	<Warning>
	This workflow works for pull requests opened from branches in the same repository. GitHub does not pass repository secrets to `pull_request` workflows from forks or Dependabot PRs.
	</Warning>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/features/ci.mdx` around lines 70 - 79, Update the sentence "Open a PR
that touches a model file and the review comment appears automatically." to add
a caveat explaining that the workflow uses the pull_request event and GitHub
hides repository secrets for PRs from forks and Dependabot; specify that the
automatic comment will only appear for PRs originating from branches within the
same repository (not forks or Dependabot PRs), and optionally add the same note
to the Troubleshooting section for visibility.

[coderabbitai]

♻️ Duplicate comments (3)

docs/cloud/features/ci.mdx (3)

94-94: ⚠️ Potential issue | 🟡 Minor

Include renames in the default diff-filter (or explicitly document exclusion).

ACM omits renamed files, so model renames can be missed from review context.

Proposed fix

-| `diff-filter` | `ACM` | File changes to include: A=Added, C=Copied, M=Modified |
+| `diff-filter` | `ACMR` | File changes to include: A=Added, C=Copied, M=Modified, R=Renamed |

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` at line 94, The table entry for `diff-filter`
currently lists `ACM` which omits renames; update the default to include rename
indicator `R` (e.g., `ACMR`) or explicitly document that renames are excluded
and must be handled separately; locate the `diff-filter` row in
docs/cloud/features/ci.mdx (the table line containing `diff-filter` and `ACM`)
and either add `R` to the allowed values or add a clarifying sentence explaining
that renamed files are not included by `ACM` and how to include them.

---

65-66: ⚠️ Potential issue | 🟠 Major

Add contents: read and document both required permissions.

With an explicit permissions block, unspecified scopes are set to none. Keeping only pull-requests: write can break actions/checkout@v4. Also, the troubleshooting text should mention both required scopes.

Proposed fix

     permissions:
+      contents: read
       pull-requests: write

-For GitHub, make sure `pull-requests: write` is set under `permissions` in the workflow file. GitHub Actions requires this explicitly to post PR comments.
+For GitHub, make sure both `contents: read` and `pull-requests: write` are set under `permissions` in the workflow file. `contents: read` is required for checkout, and `pull-requests: write` is required to post PR comments.

Also applies to: 133-134

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` around lines 65 - 66, The permissions block
currently lists only "pull-requests: write", which leaves all other scopes unset
and can break actions/checkout@v4; update the permissions block in
docs/cloud/features/ci.mdx to include both "contents: read" and "pull-requests:
write" (and update the troubleshooting text to mention both required scopes) so
readers see the complete required permissions; ensure you modify the permissions
block instances referenced (the block around the original diff and the one at
lines ~133-134) and update any nearby troubleshooting paragraph to explicitly
name both scopes.

---

87-87: ⚠️ Potential issue | 🟠 Major

Document fork/Dependabot limitations for secret-based PR workflows.

The setup depends on repository secrets in a pull_request workflow. Forked PRs and Dependabot PRs typically won’t receive those secrets, so this should be called out explicitly in troubleshooting.

Suggested addition

 **The comment says the MCP server is unreachable**

 Verify `ELEMENTARY_API_KEY` is correctly set and the MCP server is enabled for your account. See the [MCP setup guide](/cloud/mcp/setup-guide).

+**Setup doesn't work for forked PRs or Dependabot**
+
+<Warning>
+For `pull_request` workflows, GitHub does not expose repository secrets to forked PRs, and Dependabot PRs are similarly restricted. If needed, use a maintainer-triggered workflow (for example via `workflow_dispatch`) or run this only for branches in the main repository.
+</Warning>
+
 <Warning>
 If a model has never been synced through Elementary, the comment will note that no history is available yet. Results populate automatically after the next Elementary sync.
 </Warning>

Also applies to: 131-142

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` at line 87, Add an explicit troubleshooting note
to the CI docs where the sentence "That's it. Open a PR that touches a model
file and the review comment appears automatically." appears: explain that the
setup relies on repository secrets available to pull_request workflows and
therefore forked PRs and Dependabot PRs typically do not receive those secrets,
include suggested workarounds (e.g., contributors open branch PRs from same
repo, maintainers run workflow, or use a bot with push access), and add the same
clarification to the other affected block referenced in the comment (the section
covering lines 131-142) so readers know the limitation and how to proceed.

🧹 Nitpick comments (1)

docs/cloud/features/ci.mdx (1)

37-37: Clarify GitHub vs GitLab setup count in this sentence.

“Two secrets and one file” reads as global, but the GitLab flow later requires three variables. Consider wording this as GitHub-specific.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` at line 37, The sentence "Two secrets and one
file" is ambiguous because the GitLab flow requires three variables; update the
copy to state the GitHub-specific requirement (e.g., "For GitHub: two secrets
and one file") or explicitly list both platform counts so readers aren't misled;
adjust the surrounding text that references GitLab variables to ensure it says
"GitLab: three variables" or similar so the total requirements are clear.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@docs/cloud/features/ci.mdx`:
- Line 94: The table entry for `diff-filter` currently lists `ACM` which omits
renames; update the default to include rename indicator `R` (e.g., `ACMR`) or
explicitly document that renames are excluded and must be handled separately;
locate the `diff-filter` row in docs/cloud/features/ci.mdx (the table line
containing `diff-filter` and `ACM`) and either add `R` to the allowed values or
add a clarifying sentence explaining that renamed files are not included by
`ACM` and how to include them.
- Around line 65-66: The permissions block currently lists only "pull-requests:
write", which leaves all other scopes unset and can break actions/checkout@v4;
update the permissions block in docs/cloud/features/ci.mdx to include both
"contents: read" and "pull-requests: write" (and update the troubleshooting text
to mention both required scopes) so readers see the complete required
permissions; ensure you modify the permissions block instances referenced (the
block around the original diff and the one at lines ~133-134) and update any
nearby troubleshooting paragraph to explicitly name both scopes.
- Line 87: Add an explicit troubleshooting note to the CI docs where the
sentence "That's it. Open a PR that touches a model file and the review comment
appears automatically." appears: explain that the setup relies on repository
secrets available to pull_request workflows and therefore forked PRs and
Dependabot PRs typically do not receive those secrets, include suggested
workarounds (e.g., contributors open branch PRs from same repo, maintainers run
workflow, or use a bot with push access), and add the same clarification to the
other affected block referenced in the comment (the section covering lines
131-142) so readers know the limitation and how to proceed.

---

Nitpick comments:
In `@docs/cloud/features/ci.mdx`:
- Line 37: The sentence "Two secrets and one file" is ambiguous because the
GitLab flow requires three variables; update the copy to state the
GitHub-specific requirement (e.g., "For GitHub: two secrets and one file") or
explicitly list both platform counts so readers aren't misled; adjust the
surrounding text that references GitLab variables to ensure it says "GitLab:
three variables" or similar so the total requirements are clear.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0c4bb0e6-07d6-4a77-a89e-4c8febca7e63

📥 Commits

Reviewing files that changed from the base of the PR and between 593c561 and cbcc61b.

📒 Files selected for processing (1)

• docs/cloud/features/ci.mdx

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/cloud/features/ci.mdx`:
- Around line 57-59: The pull_request workflow paths only include
"models/**/*.yml" so changes to ".yaml" files won't trigger reviews; update the
pull_request.paths configuration to also include the "models/**/*.yaml" pattern
(alongside the existing "models/**/*.yml") so repositories using .yaml extension
are covered; edit the paths section in the CI config where the two entries
"models/**/*.sql" and "models/**/*.yml" are declared and add "models/**/*.yaml".

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 24803a98-7d41-4001-838f-0c7e95c3b2af

📥 Commits

Reviewing files that changed from the base of the PR and between cbcc61b and c287204.

📒 Files selected for processing (1)

• docs/cloud/features/ci.mdx

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Include .yaml in pull_request.paths to avoid missed reviews.

The trigger currently matches models/**/*.yml but not models/**/*.yaml. Repos using .yaml model files will not run this workflow when those files change.

Suggested fix

 on:
   pull_request:
     paths:
       - "models/**/*.sql"
       - "models/**/*.yml"
+      - "models/**/*.yaml"
       - "dbt_project.yml"

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	paths:
	- "models/**/*.sql"
	- "models/**/*.yml"
	paths:
	- "models/**/*.sql"
	- "models/**/*.yml"
	- "models/**/*.yaml"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud/features/ci.mdx` around lines 57 - 59, The pull_request workflow
paths only include "models/**/*.yml" so changes to ".yaml" files won't trigger
reviews; update the pull_request.paths configuration to also include the
"models/**/*.yaml" pattern (alongside the existing "models/**/*.yml") so
repositories using .yaml extension are covered; edit the paths section in the CI
config where the two entries "models/**/*.sql" and "models/**/*.yml" are
declared and add "models/**/*.yaml".

[joostboon]

Thanks for the thorough review @coderabbitai! All four issues addressed in c287204:

• contents: read permission — added alongside pull-requests: write in the workflow permissions block. Without it, actions/checkout fails when the repo uses restricted default permissions.
• Fork/Dependabot caveat — added a Warning callout after the setup steps noting that pull_request workflows don't receive secrets from forks or Dependabot PRs.
• diff-filter default updated to ACMR — now includes renamed models. Updated in the docs, action.yml, and the GitLab template.
• Troubleshooting note — updated to mention both contents: read and pull-requests: write as required permissions.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@joostboon: Thank you for the detailed summary — all four fixes look great!

• ✅ contents: read + pull-requests: write — correct pairing; the checkout step silently fails without the read permission under restricted defaults.
• ✅ Fork/Dependabot Warning callout — important caveat for users who might wonder why the workflow runs but no comment is posted.
• ✅ diff-filter: ACMR across docs, action.yml, and the GitLab template — good catch including renamed models; keeping all three in sync avoids drift.
• ✅ Troubleshooting note updated to list both permissions — makes self-diagnosis much easier.

The documentation looks solid end-to-end now. 🎉

---

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

[joostboon]

Closing in favor of a clean branch - the head branch was mistakenly cut from master instead of docs, causing 772 files changed.