Re-adds run-kernel-e2e-packaged: instead of build:native, npm ci installs
the published @databricks/databricks-sql-kernel-linux-x64-gnu from JFrog
db-npm, asserts the binding loads from node_modules (not a local build),
and runs the SELECT 1 e2e against it — validating the optionalDependencies
path a released driver actually uses, which build:native never covers.
Now that the kernel scope is allowlisted through db-npm curation, this
resolves and passes. Same gate/runner/warehouse as run-kernel-e2e.
Co-authored-by: Isaac
Signed-off-by: Madhavendra Rathore <madhavendra.rathore@databricks.com>
Summary
Re-adds the run-kernel-e2e-packaged job to kernel-e2e.yml. Unlike run-kernel-e2e (which builds the binding via build:native), this job installs the published @databricks/databricks-sql-kernel-<triple> package via npm ci (the optionalDependencies a released driver uses, resolved through JFrog db-npm), asserts the binding loads from node_modules (not a local build), and runs the SELECT 1 e2e against it.
This is the only CI coverage of the path a real npm install consumer takes — build:native never exercises it.
Why now
It was dropped from the consume PR (#434) because the kernel 0.2.0 packages were blocked by JFrog db-npm's 7-day curation cooldown, so npm ci couldn't resolve them. The scope is now allowlisted through curation, so the packages resolve and this job passes — verified by the unit-test matrix (incl. Node 14) now going green on main.
What it does
Same gate (detect-changes), runner, and azure-prod environment as run-kernel-e2e. No custom check — its own job status is the signal.
This pull request and its description were written by Isaac.