Bumps [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) from 4
to 5.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/astral-sh/setup-uv/releases">astral-sh/setup-uv's
releases</a>.</em></p>
<blockquote>
<h2>v5.0.0 🎄 Merry Christmas - Help fastly and users by default</h2>
<h2>Changes</h2>
<p>This christmans 🎄 release is a bit early bit still full of presents 🎁
Since we are changing some of the defaults this can lead to breaking
changes, thus the major version increase.</p>
<p>Here are the highlights:</p>
<h3><a
href="https://redirect.github.com/astral-sh/setup-uv/pull/193">Default
to enable-cache: true on GitHub hosted runners</a></h3>
<p>Did you know that that Fastly, the company hosting PyPI,
theoretically has to pay $12.5 million per month and so far have served
more than 2.41 <strong>exabytes</strong> of data?
<img
src="https://github.com/user-attachments/assets/f2f6cb3f-68f6-4e37-abb1-d3bf1f278533"
alt="image" /></p>
<p>This is why <a
href="https://redirect.github.com/astral-sh/setup-uv/issues/54">they
asked us</a> to turn on caching by default. After weighting the pros and
cons we decided to automatically upload the cache to the GitHub Actions
cache when running on GitHub hosted runners. You can still disable that
with <code>enable-cache: false</code>.</p>
<p>I remember when I first got into actions and didn't understand all
the magic. I was baffled that some actions did something behind the
scenes to make everything faster. I hope with this change we help a lot
of users who are don't want to or are afraid to understand what
<code>enable-cache</code> does.</p>
<h3><a
href="https://redirect.github.com/astral-sh/setup-uv/pull/185">Add
**/requirements*.txt to default cache-dependency-glob</a></h3>
<p>If caching is enabled we automatically searched for a
<code>uv.lock</code> file and when this changed we knew we had to
refresh the cache. A lot of projects don't use this but rather the good
old <code>requirements.txt</code>. We now automatically search for both
<code>uv.lock</code>and <code>requirements*.txt</code> (this means also
<code>requirements-test.txt</code>, <code>requirements-dev.txt</code>,
...) files.
You can change this with <code>cache-dependency-glob</code></p>
<h3><a
href="https://redirect.github.com/astral-sh/setup-uv/pull/194">Auto
activate venv when python-version is set</a></h3>
<p>Some workflows install packages on the fly. This automatically works
when using a python version that is already present on the runner. But
if uv installs the version, e.g. because it is a free-threaded version
or an old one, it is a <a
href="https://astral.sh/blog/python-build-standalone">standalone-build</a>
and installing packages "into the system" is not possible.</p>
<p>We now automatically create a new virtual environment with <code>uv
venv</code> and activate it for the rest of the workflow if
<code>python-version</code> is used. This means you can now do</p>
<pre lang="yaml"><code>- name: Install uv
uses: astral-sh/setup-uv@auto-environment
with:
python-version: 3.13t
- run: uv pip install -i
https://pypi.anaconda.org/scientific-python-nightly-wheels/simple cython
</code></pre>
<h2>🚨 Breaking changes</h2>
<ul>
<li>Default to enable-cache: true on GitHub hosted runners <a
href="https://github.com/eifinger"><code>@eifinger</code></a> (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/193">#193</a>)</li>
<li>Add **/requirements*.txt to default cache-dependency-glob <a
href="https://github.com/eifinger"><code>@eifinger</code></a> (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/185">#185</a>)</li>
</ul>
<h2>🐛 Bug fixes</h2>
<ul>
<li>Always use api.github.com <a
href="https://github.com/eifinger"><code>@eifinger</code></a> (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/191">#191</a>)</li>
</ul>
<h2>🚀 Enhancements</h2>
<ul>
<li>Auto activate venv when python-version is set <a
href="https://github.com/eifinger"><code>@eifinger</code></a> (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/194">#194</a>)</li>
<li>Add python version to cache key <a
href="https://github.com/eifinger"><code>@eifinger</code></a> (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/187">#187</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="887a942a15"><code>887a942</code></a>
Set VIRTUAL_ENV to .venv instead of .venv/bin (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/210">#210</a>)</li>
<li><a
href="d174a24c07"><code>d174a24</code></a>
Align use of <code>actions/setup-python</code> with uv docu (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/207">#207</a>)</li>
<li><a
href="12c852e6ba"><code>12c852e</code></a>
Remove uv version from cache key (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/206">#206</a>)</li>
<li><a
href="180f8b4439"><code>180f8b4</code></a>
Fix wrong cacheDependencyPathHash (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/201">#201</a>)</li>
<li><a
href="e3fb95a689"><code>e3fb95a</code></a>
Warn instead of fail for no-dependency-glob (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/200">#200</a>)</li>
<li><a
href="2af22b5b2d"><code>2af22b5</code></a>
chore: update known checksums for 0.5.11 (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/198">#198</a>)</li>
<li><a
href="dd578776bb"><code>dd57877</code></a>
Auto activate venv when python-version is set (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/194">#194</a>)</li>
<li><a
href="85aa0bf0c1"><code>85aa0bf</code></a>
chore: update known checksums for 0.5.10 (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/196">#196</a>)</li>
<li><a
href="1f2cbfa7bb"><code>1f2cbfa</code></a>
Bump <code>@types/node</code> from 22.10.1 to 22.10.2 (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/189">#189</a>)</li>
<li><a
href="25b3ce6330"><code>25b3ce6</code></a>
chore: update known checksums for 0.5.9 (<a
href="https://redirect.github.com/astral-sh/setup-uv/issues/195">#195</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/astral-sh/setup-uv/compare/v4...v5">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Giving 7 days to react before closing is too aggressive, IMO. Changed it
to 30.
Also changed 'stale' label from 30d to 60d.
Also removed dry-run setting, it does not appear to do anything.
## Changes
This workflow only worked if it was triggered on the tag to publish
itself. This means it is not possible to release a version if the
workflow configuration at that tag is broken (as is the case for
v0.238.0 because of #2105).
This change adds a "tag" input that can be set when manually triggering
the workflow.
## Tests
* Succesful run with this change:
https://github.com/databricks/cli/actions/runs/12689281843
* Pull request that the run created:
https://github.com/microsoft/winget-pkgs/pull/209220
## Changes
This action uses a token to access the release artifacts and, as such,
needs to execute on the runner that's on the allowlist.
Related PRs:
* #2098
* #2077
## Changes
This reverts commit 31552852ff.
These workflows were disabled in #2085.
They should work again now that we're using self-hosted runners (see
#2077).
## Tests
(inline)
## Changes
Migrate workflows to Databricks-hosted GitHub Actions runners.
The GitHub-hosted runners can no longer be used because of security
hardening.
## Changes
The comment block appears on all PRs, even if the integration tests are
automatically triggered. This is quite noisy. This change limits those
comments to PRs from forks.
## Tests
Have to try by merging...
On main branch: ‘make test’ takes about 33s
On this branch: ‘make test’ takes about 2.7s
(all measurements are for hot cache)
What’s done (from highest impact to lowest):
- Remove -coverprofile= option - this option was disabling "go test"'s
built-in cache and also it took extra time to calculate the coverage
(extra 21s).
- Exclude ./integration/ folder, there are no unit tests there, but
having it included adds significant time. "go test"'s caching also does
not work there for me, due to TestMain() presence (extra 7.2s).
- Remove dependency on "make lint" - nice to have, but slow to re-check
the whole repo and should already be done by IDE (extra 2.5s).
- Remove dependency on "make vendor" — rarely needed; on CI it is
already executed separately (extra 1.1s).
The coverage option is still available under "make cover". Use "make
showcover" to show it.
I’ve also removed separate "make testonly". If you only want tests, run
"make test". If you want lint+test run "make lint test" etc.
I've also modified the test command, removed unnecessary -short, -v,
--raw-command.
## Changes
I noticed a diff in the schema in #2052.
This check should be performed automatically.
## Tests
This PR includes a commit that changes the schema to check that the
workflow actually fails.
## Changes
Simplify logic for selecting Python to run when calculating default whl
build command: "python" on Windows and "python3" everywhere.
Python installers from python.org do not install python3.exe. In
virtualenv there is no python3.exe.
## Tests
Added new unit tests to create real venv with uv and simulate activation
by prepending venv/bin to PATH.
## Changes
The existing workflow already had 2 trigger conditions, so instead of
adding a third (and seeing more "skipped" jobs), I split them up into
dedicated workflow files, each with their own trigger condition.
The integration test status is reported back via commit status.
## Tests
We can confirm that everything works as expected as this PR moves from
here to the merge group to main.
## Changes
Adds annotations to json-schema for fields which are not covered by
OpenAPI spec.
Custom descriptions were copy-pasted from documentation PR which is
still WIP so descriptions for some fields are missing
Further improvements:
* documentation autogen based on json-schema
* fix missing descriptions
## Tests
This script is not part of CLI package so I didn't test all corner
cases. Few high-level tests were added to be sure that schema
annotations is in sync with actual config
---------
Co-authored-by: Pieter Noordhuis <pieter.noordhuis@databricks.com>
Remove unnecessary make command and github workflow - it's a subset of
"lint" now. However, keep "mod tidy" separately, don't think the linter
does that.
## Changes
Old script could not be run from master due to security restrictions and
there is no reliable way to detect if a user as secrets.
## Tests
Opened a PR in SDK Java from fork
https://github.com/databricks/databricks-sdk-java/pull/375
## Changes
This was released 2+ months ago so it has baked enough.
Blog post: https://go.dev/blog/go1.23.
## Tests
None other than unit and integration tests.
## Changes
Automatically trigger integration tests when a PR is opened or updated
## Tests
Workflow below.
---------
Co-authored-by: Pieter Noordhuis <pieter.noordhuis@databricks.com>
## Changes
The goreleaser jobs perform a cross-platform build of the main binary
without test files. It should use a different cache than the jobs that
run tests for a single platform.
This change also updates the `release-snapshot` job to use the latest
goreleaser action, as was done in #1477.
## Tests
Ran `release-snapshot` job from this PR.
## Changes
We are starting to sign Windows CLI executables, but this has to be done
from a machine with a Yubikey storing the signing certificate for the
immediate future. As such, we will only trigger Winget publishing once
the signed binaries have been uploaded to Github.
Additionally, as an extra precaution, we will only release the signed
binaries via Winget.
## Tests
<!-- How is this tested? -->
## Changes
This PR makes changes to support creating a docker image for the CLI
with the `terraform` dependencies built in. This is useful for customers
that operate in a network-restricted environment. Normally DABs makes
API calls to registry.terraform.io to setup the terraform dependencies,
with this setup the CLI/DABs will rely on the provider binaries bundled
in the docker image.
### Specifically this PR makes the following changes:
----------------
Modifies the CLI release workflow to publish the docker images in the
Github Container Registry. URL:
https://github.com/databricks/cli/pkgs/container/cli.
We use docker support in `goreleaser` to build and publish the images.
Using goreleaser ensures the CLI packaged in the docker image is the
same release artifact as the normal releases. For more information see:
1. https://goreleaser.com/cookbooks/multi-platform-docker-images
2. https://goreleaser.com/customization/docker/
Other choices made include:
1. Using `alpine` as the base image. The reason is `alpine` is a small
and lightweight linux distribution (~5MB) and an industry standard.
2. Not using [docker
manifest](https://docs.docker.com/reference/cli/docker/manifest) to
create a multi-arch build. This is because the functionality is still
experimental.
------------------
Make the `DATABRICKS_TF_VERSION` and `DATABRICKS_TF_PROVIDER_VERSION`
environment variables optional for using the terraform file mirror.
While it's not strictly necessary to make the docker image work, it's
the "right" behaviour and reduces complexity. The rationale is:
- These environment variables here are needed so the Databricks CLI does
not accidentally use the file mirror bundled with VSCode if it's
incompatible. This does not require the env vars to be mandatory.
context: https://github.com/databricks/cli/pull/1294
- This makes the `Dockerfile` and `setup.sh` simpler. We don't need an
[entrypoint.sh script to set the version environment
variables](https://medium.com/@leonardo5621_66451/learn-how-to-use-entrypoint-scripts-in-docker-images-fede010f172d).
This also makes using an interactive terminal with `docker run -it ...`
work out of the box.
## Tests
Tested manually.
--------------------
To test the release pipeline I triggered a couple of dummy releases and
verified that the images are built successfully and uploaded to Github.
1. https://github.com/databricks/cli/pkgs/container/cli
3. workflow for release:
https://github.com/databricks/cli/actions/runs/8646106333
--------------------
I tested the docker container itself by setting up
[Charles](https://www.charlesproxy.com/) as an HTTP proxy and verifying
that no HTTP requests are made to `registry.terraform.io`
Before:
FYI, The Charles web proxy is hosted at localhost:8888.
```
shreyas.goenka@THW32HFW6T bundle-playground % rm -r .databricks
shreyas.goenka@THW32HFW6T bundle-playground % HTTP_PROXY="http://localhost:8888" HTTPS_PROXY="http://localhost:8888" cli bundle deploy
Uploading bundle files to /Users/shreyas.goenka@databricks.com/.bundle/bundle-playground/default/files...
Deploying resources...
Updating deployment state...
Deployment complete!
```
<img width="1275" alt="Screenshot 2024-04-11 at 3 21 45 PM"
src="https://github.com/databricks/cli/assets/88374338/15f37324-afbd-47c0-a40e-330ab232656b">
After:
This time bundle deploy is run from inside the docker container. We use
`host.docker.internal` to map to localhost on the host machine, and -v
to mount the host file system as a volume.
```
shreyas.goenka@THW32HFW6T bundle-playground % docker run -v ~/projects/bundle-playground:/bundle -v ~/.databrickscfg:/root/.databrickscfg -it --entrypoint /bin/sh -e HTTP_PROXY="http://host.docker.internal:8888" -e HTTPS_PROXY="http://host.docker.internal:8888" --network host ghcr.io/databricks/cli:latest-arm64
/ # cd /bundle/
/bundle # rm -r .databricks/
/bundle # databricks bundle deploy
Uploading bundle files to /Users/shreyas.goenka@databricks.com/.bundle/bundle-playground/default/files...
Deploying resources...
Updating deployment state...
Deployment complete!
```
<img width="1275" alt="Screenshot 2024-04-11 at 3 22 54 PM"
src="https://github.com/databricks/cli/assets/88374338/2a8f097e-734b-4b3e-8075-c02e98a1b275">
## Changes
This PR fixes bundle schema being broken because `for_each_task: null`
was set in the generated schema. This is not valid according to the JSON
schema specification and thus the Red Hat YAML VSCode extension was
failing to parse the YAML configuration.
This PR fixes: https://github.com/databricks/cli/issues/1312
## Tests
The fix itself was tested manually. I asserted that the autocompletion
works now. This was mistakenly overlooked the first time around when the
regression was introduced in https://github.com/databricks/cli/pull/1204
because the YAML extension provides best-effort autocomplete suggestions
even if the JSON schema fails to load.
To prevent future regressions we also add a test to assert that the JSON
schema generated itself is a valid JSON schema object. This is done via
using the `ajv-cli` to validate the schema. This package is also used by
the Red Hat YAML extension and thus provides a high fidelity check for
ensuring the JSON schema is valid.
Before, with the old schema:
```
shreyas.goenka@THW32HFW6T cli-versions % ajv validate -s proj/schema-216.json -d ../bundle-playground-3/databricks.yml
schema proj/schema-216.json is invalid
error: schema is invalid: data/properties/resources/properties/jobs/additionalProperties/properties/tasks/items/properties/for_each_task must be object,boolean, data/properties/resources/properties/jobs/additionalProperties/properties/tasks/items must be array, data/properties/resources/properties/jobs/additionalProperties/properties/tasks/items must match a schema in anyOf
```
After, with the new schema:
```
shreyas.goenka@THW32HFW6T cli-versions % ajv validate -s proj/schema-dev.json -d ../bundle-playground-3/databricks.yml
../bundle-playground-3/databricks.yml valid
```
After, autocomplete suggestions:
<img width="600" alt="Screenshot 2024-03-27 at 6 35 57 PM"
src="https://github.com/databricks/cli/assets/88374338/d0a62402-e323-4f36-854d-332b33cbeab8">
## Changes
This PR adds a release workflow which will automatically publish the CLI
to winget-pkgs whenever a release is made. It uses
https://github.com/vedantmgoyal2009/winget-releaser to release the
windows binaries. @exorcism0666 has been graciously making releases on
our behalf, but we can do this automatically ourselves after this PR.
## Tests
<!-- How is this tested? -->
## Changes
This was pinned to 1.21.0 and included a vulnerability as reported in
#1150. The vulnerability does not affect the prior CLI releases as it
requires a user to execute Go commands from within compromised module
directories.
Fixes#1150.
## Changes
This silences the following warning as seen in action output:
> Node.js 16 actions are deprecated. Please update the following actions
to use Node.js 20: actions/setup-go@v4.
dependabot[bot]
Denis Bilenko
Pieter Noordhuis
Andrew Nester
Ilya Kuznetsov
hectorcast-db
shreyas-goenka
Miles Yucht