Add Greptile rule to flag missing databricks CI tag on test changes

.greptile/config.json

@@ -132,6 +132,12 @@
       "rule": "Verify dependency version alignment across all build profiles and shaded JAR consistency.",
       "scope": ["pom.xml", "**/pom.xml", "build/**"],
       "severity": "medium"
+    },
+    {
+      "id": "databricks-ci-tag",
+      "rule": "Databricks pre-merge CI auto-runs only when the diff touches a 'sql-plugin/src/main/...db/' shim dir or a path containing 'databricks'. The Databricks pre-merge builds with -DskipTests and runs only the Python integration tests (run_pyspark_from_build.sh); Scala unit tests are never executed on Databricks, so the '[databricks]' tag is only meaningful for integration_tests/** changes (hence this rule's scope). For an integration test or its utilities that could behave differently on Databricks — filesystem/path semantics (local vs DBFS/abfss, file:// scheme, os.walk/os.path.getsize), or optimizer/plan-string assertions (alias names and plan rendering differ on DBR) — where the PR title lacks the '[databricks]' tag, recommend adding it (or confirming Databricks coverage another way), because the standard Linux pre-merge does not run Databricks and DBR-only failures will otherwise surface later on an unrelated PR. Do NOT flag changes that already touch a *db* shim path (auto-covered) or doc-only changes.",
+      "scope": ["integration_tests/**"],
+      "severity": "medium"
     }
   ]
 }

.greptile/rules.md

@@ -16,5 +16,6 @@ shim layer architecture, see `AGENTS.md` at the repo root.
 - [ ] H4: Test quality — no GPU execution verification, hardcoded sleeps, unseeded random data; GPU resource cleanup in afterAll/afterEach
 - [ ] H5: Configuration — new RapidsConf without docs/defaults; should use .internal() if not user-visible; new features default off
 - [ ] H6: Magic numbers — unexplained numeric literals without named constants or comments
-- [ ] H7: Pre-merge CI gaps — only selected shims run unit tests; [databricks] needed for DB CI; feature-gated tests need explicit enable; limited Scala 2.13 coverage
+- [ ] H7: Pre-merge CI gaps — only selected shims run unit tests; feature-gated tests need explicit enable; limited Scala 2.13 coverage
 - [ ] H8: Upstream dependencies — SNAPSHOT changes from spark-rapids-jni/cudf may break; verify API usage against upstream repos
+- [ ] H9: Databricks coverage — change may behave differently on Databricks (filesystem/path semantics, plan-string/optimizer assertions, DBR Spark-fork runtime) but the PR title lacks [databricks] and the diff doesn't touch a *db* shim path or a path containing `databricks` (either auto-triggers DB CI). Recommend [databricks] or confirm DB validation (see AGENTS.md § PR title tags)

AGENTS.md

@@ -12,7 +12,7 @@ This document provides context for AI coding agents (Claude Code, GitHub Copilot
 - **Sign-off required** — all commits must use `git commit -s` for DCO compliance
 - **No rebase during review** — if a PR is under review, do not rebase; merge the base branch instead to preserve reviewer comment context
 - **Scala 2.13 sync** — after modifying any `pom.xml`, run `./build/make-scala-version-build-files.sh 2.13`
-- **PR title tags** — use `[databricks]` to trigger Databricks CI, `[skip ci]` for doc-only changes
+- **PR title tags** — `[databricks]` triggers Databricks pre-merge CI; `[skip ci]` for doc-only changes. Databricks CI auto-runs only when the diff touches a `sql-plugin/src/main/…db/` shim dir or a path containing `databricks`; otherwise it does **not** run. Add `[databricks]` manually when a change could behave differently on Databricks without touching those paths — e.g. integration tests that depend on filesystem/path semantics (local vs DBFS/`abfss`, `file://` scheme, `os.walk`/`os.path`), or optimizer/plan-string assertions (alias names and plan rendering differ on DBR) — since the Linux pre-merge will not catch DBR-only failures
 
 ## Build Commands