Thank you for your interest in contributing! This document explains how to set up your environment, make a change, and open a pull request.
If you find a bug or have a feature request, please file an issue: https://github.com/databricks/databricks-vscode/issues/new
When reporting a bug, please attach the extension logs as described here: https://docs.databricks.com/dev-tools/vscode-ext.html#send-usage-logs-to-databricks
- Node.js
>=22 - Yarn
3.2.x(the repo pinsyarn@3.2.1viapackageManager) - Python (for the Python-side unit tests and the bundled runtime scripts)
Prepare Yarn and install dependencies:
npm install -g yarn@3
yarn installThe Databricks JavaScript SDK (@databricks/sdk-experimental) is a regular npm
dependency and is installed automatically by yarn install — no separate step
is required.
Fetch the Databricks CLI that the extension bundles:
yarn workspace databricks run package:cli:fetchRe-run this whenever cli.version in packages/databricks-vscode/package.json
changes — after every git pull, in practice.
After that you're ready to build, run, and test the extension.
Build all workspaces:
yarn buildTo develop the extension interactively, open the repository in VSCode and press
F5 to launch the Extension Development Host. Use the watch script for
incremental rebuilds while you work:
yarn workspace databricks run watchRun the full check (lint + unit tests) across all workspaces from the repo root:
yarn testWithin the databricks-vscode package you can run the individual suites:
# Lint (eslint + prettier check)
yarn workspace databricks run test:lint
# TypeScript unit tests (VSCode test runner)
yarn workspace databricks run test:unit
# Python unit tests
yarn workspace databricks run test:python
# Unit tests with coverage
yarn workspace databricks run test:cov
# End-to-end / integration tests (see "Integration test environment" below —
# these require a live Databricks workspace and extra environment variables)
yarn workspace databricks run test:integPlease add tests for any new behavior, and make sure the full suite passes before opening a pull request.
Unlike the lint and unit suites, test:integ runs against a live Databricks
workspace, so it needs credentials and a cluster before it will start. The
e2e runner resolves authentication through the standard Databricks SDK unified
auth (environment variables or a .databrickscfg profile), and it asserts that
a default cluster is configured.
Set the following before running yarn workspace databricks run test:integ:
| Variable | Required | Description |
|---|---|---|
DATABRICKS_HOST |
Yes | Workspace URL, e.g. https://my-workspace.cloud.databricks.com. |
TEST_DEFAULT_CLUSTER_ID |
Yes | ID of an existing cluster in that workspace; the runner starts it before the tests. |
DATABRICKS_TOKEN |
For PAT auth | Personal access token. Provide this or the OAuth pair below. |
DATABRICKS_CLIENT_ID / DATABRICKS_CLIENT_SECRET |
For OAuth (M2M) auth | Service principal credentials, used when no token is set. |
For example, using a personal access token:
export DATABRICKS_HOST="https://my-workspace.cloud.databricks.com"
export DATABRICKS_TOKEN="dapi..."
export TEST_DEFAULT_CLUSTER_ID="0101-234567-abcdefgh"
yarn workspace databricks run test:integInstead of exporting DATABRICKS_HOST/DATABRICKS_TOKEN you may point the SDK
at an existing profile (for example export DATABRICKS_CONFIG_PROFILE=DEFAULT);
TEST_DEFAULT_CLUSTER_ID is still required in that case. The extension e2e tests
also build a .vsix package as part of test:integ:prepare, so make sure you
have run yarn build first.
Formatting and linting are enforced by prettier and eslint. Auto-fix formatting and lint issues with:
yarn fixCI runs yarn test, which includes test:lint, so unformatted or lint-failing
code will not pass.
- Fork the repository and create a topic branch from
main. - Keep each PR focused on a single change; split unrelated fixes or refactors into separate PRs.
- Make sure
yarn testpasses and add tests for new behavior. - Fill in the PR template — describe what changed and how it was tested.
- Open your pull request. You do not need to sign anything up front — a maintainer will request the Contributor License Agreement during review if your change is accepted (see below).
This project is licensed under the Databricks License. To accept contributions, we need to confirm that you have the right to submit your contribution and that you grant Databricks the right to distribute it. For projects under the Databricks License this is done through a Contributor License Agreement (CLA) rather than a DCO commit sign-off.
The CLA is handled manually by the maintainers — there is no self-service form to sign in advance:
- Open your pull request as normal. There is no need to sign anything before you do — just author your commits with your real name and email (git records these automatically).
- A maintainer reviews your change. If we would like to accept it, we will send you the Databricks CLA and ask you, in a PR comment, to sign and return it.
- Sign the CLA and return it as instructed, then confirm on the pull request.
- We merge once the signed CLA is in place and the review is complete.
Notes:
- If you are contributing on behalf of a company, you may need internal approval to sign the CLA, and it may require signature from an officer of the company. Please start this process early so it doesn't block your PR.
- Once the CLA is signed it covers subsequent contributions from the same contributor or company — you only need to sign once.
By contributing, you agree that your contributions will be licensed under the terms of the LICENSE in this repository (the Databricks License).