Turns out that the existing CI step for Nightly did create the licenses
and they have been baked into X86 builds ever since, because our
builders are stateful.
On ARM machines, the licenses wouldn't exist in the binary because we
called `script/generate-licenses` too late in `scripts/bundle-linux`,
after the binary had been created.
This removes the duplication and generates the licenses once, before the
binary is created.
Fixes#14302.
Release Notes:
- Fixed "View Dependency Licenses" (or `zed: open licenses`) crashing on
Linux ARM machines.
([#14302](https://github.com/zed-industries/zed/issues/14302)
Fixes https://github.com/zed-industries/zed/issues/13073
Note that, contrary to the issue's text, we're still shipping a
statically bundled sqlite3 after this PR. We use enough new features of
sqlite, like `sqlite3_error_offset` and `STRICT`, that our minimum
version (v3.38.0) is higher than is presumably accessible on Ubuntu.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This fixes an extra 10 second delay when needing to recompile xtask, and
allows passing arbitrary clippy args (like --allow-dirty)
Release Notes:
- N/A
Note:
- We have disabled all tests that rely on Postgres in the Linux CI. We
only really need to test these once, and as macOS is our team's primary
platform, we'll only enable them on macOS for local reproduction.
- We have disabled all tests that rely on the font metrics. We
standardized on Zed Mono in many fonts, but our CoreText Text System and
Cosmic Text System proved to be very different in effect. We should
revisit if we decide to standardize our text system across platforms
(e.g. using Harfbuzz everywhere)
- Extended the condition timeout significantly. Our CI machines are slow
enough that this is causing spurious errors in random tests.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR removes the references to initializing Git submodules as part of
building Zed.
These are no longer needed, as our only submodule was removed in #11672.
Release Notes:
- N/A
To speed up Linux CI builds, use a set of self-hosted Linux machines and
use them to run all slow CI steps for Linux: "tests", bundling and
nightly builds.
Also adds a set of dev icons as Linux bundling script required them for
`run-bundling`-tagged builds from regular PRs.
Same icons as for Preview were used, but, ideally, something different
could be created.
Release Notes:
- N/A
This PR sets up deployments for the docs using mdBook.
Right now the new docs are hosted at
[zed.dev/docs2](https://zed.dev/docs2/).
The docs are deployed to Cloudflare Pages on merges to `main`, and we
have a Cloudflare Worker that routes traffic from `zed.dev/docs2` to the
docs deployment.
We can iterate on the docs for a bit, and then promote them to
`zed.dev/docs` when we're all ready for the switchover.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR addresses some issues I ran into with the way we draft release
notes in CI when doing builds.
The first issue I encountered was that `script/draft-release-notes` was
failing, seemingly due to CI doing a shallow Git checkout and not having
all of the tags available in order to compare then. This was addressed
by setting the `fetch-depth` during the Git checkout.
The second issue is that (in my opinion) we shouldn't fail the build if
drafting release notes fails. After well, we're doing it as a
convenience to ourselves, and it isn't a mandatory part of the build.
This was addressed by making any failures in
`script/draft-release-notes` not fail the CI step as a whole.
These changes were already applied to the `v0.133.x` branch.
Release Notes:
- N/A
While I don't expect these to be useful for our weekly minor releases, I
hope that this will save a step for people doing mid-week patches.
Release Notes:
- N/A
Add `./script/trigger-release {nightly|stable|preview}`
This command can be run regardless of the state of your local git
repository, and it
either triggers a workflow run of `bump_patch_version.yml` (for
stable/preview) or
it force pushes the nightly tag.
Also add some docs on releases to explain all of this.
Release Notes:
- N/A
This PR updates Danger to proxy its requests to GitHub through a proxy
service.
## Motivation
Currently Danger is not able to run on PRs opened from forks of Zed.
This is due to GitHub Actions' security policies. Forks are not able to
see any of the repository secrets, and the built-in
`secrets.GITHUB_TOKEN` has its permissions
[restricted](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
to only reads when running on forks.
I asked around on the Danger repo, and some big projects
(DefinitelyTyped) are working around this by using a publicly-listed
(although slightly obfuscated) token:
https://github.com/danger/danger-js/issues/918#issuecomment-2048629487.
While this approach is _probably_ okay given the limited scope and
permissions of the GitHub token, I would still prefer a solution that
avoids disclosing the token at all.
## Explanation
I ended up writing a small proxy service, [Danger
Proxy](https://github.com/maxdeviant/danger-proxy), that can be used to
provide Danger with the ability to make authenticated GitHub requests,
but without disclosing the token.
From the README:
> Danger Proxy will:
>
> - Proxy all requests to `/github/*` to the GitHub API. The provided
GitHub API token will be used for authentication.
> - Restrict requests to the list of repositories specified in the
`ALLOWED_REPOS` environment variable.
> - Restrict requests to the subset of the GitHub API that Danger
requires.
I have an instance of this service deployed to
[danger-proxy.fly.dev](https://danger-proxy.fly.dev/).
Release Notes:
- N/A
This PR adds a GitHub Action for publishing the extension CLI.
When the `extension-cli` tag is pushed, this Action will run, build the
`zed-extension` binary, and upload it to DigitalOcean for consumption.
This will allow us to consume the pre-built binary in the CI for the
extensions repo.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
In this PR, we've added two new methods that LSP extensions can call:
* `shell_env()`, for retrieving the environment variables set in the
user's default shell in the worktree
* `which(command)`, for looking up paths to an executable (accounting
for the user's shell env in the worktree)
To test this out, we moved the `uiua` language support into an
extension. We went ahead and removed the built-in support, since this
language is extremely obscure. Sorry @mikayla-maki. To continue coding
in Uiua in Zed, for now you can `Add Dev Extension` from the extensions
pane, and select the `extensions/uiua` directory in the Zed repo. Very
soon, we'll support publishing these extensions so that you'll be able
to just install it normally.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
This PR adds a script for setting up the WASI dependencies needed for
extensions.
These already get downloaded when needed when using Zed, but in the
tests the HTTP client is faked out, so if you don't already have them
installed the `test_extension_store_with_gleam_extension` test will
fail.
Release Notes:
- N/A
This PR provides WASM extensions with write access to their own specific
working directory under the Zed `extensions` dir. This directory is set
as the extensions `current_dir` when they run. Extensions can return
relative paths from the `Extension::language_server_command` method, and
those relative paths will be interpreted relative to this working dir.
With this functionality, most language servers that we currently build
into zed can be installed using extensions.
Release Notes:
- N/A
Changes Zed CI to build and upload Linux nightly bundles.
* `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based
workflows more convenient
* renames `run-build-dmg` label into `run-bundling`, also renames a few
GH Actions entries to be more generic
* make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact.
* adds a `*.deb` package building with a couple of caveats, marked with
new `TODO linux` entries:
1. `cargo-bundle` is not very flexible, so it generates artifacts with
the structure and names that we're unable to alter before/during the
generation.
For that, a set of extra steps is made by repacking the *.deb package —
this is not very portable between different Linux distros, so later one
needs to find a way to combine multiple package types in this script.
2. `cargo-bundle` is not able to properly generate the *.msi bundle
despite declaring it in the features:
https://github.com/burtonageo/cargo-bundle/issues/116
Windows needs to invent its own way of bundling or fix the tool.
3. Both `cli` and `zed` binaries are added into the archive under
`/usr/local/bin/` path with their `-$channel` suffix
(-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed ->
/usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed
launcher:
```
~/work/zed kb/linux-nightly:origin/kb/linux-nightly* ❯ dpkg -c target/zed_amd64.deb
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/
-rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly
-rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/
-rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/
-rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/
-rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png
lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly
```
But the CLI does not work under Linux yet and there's no way to install
that CLI from Zed now; Zed binary itself is not able to open
`file/location:12:34`-like things and set up the env properly, but is
able to start or open a directory.
So, this structure can be considered temporary and changed, if needed.
4. Zed Nightly on Linux does not know how to update itself, so all
nightly publishing is not picked up automatically.
5. Rust cache from `main` builds does not get shared between CI jobs,
due to being run in a different CI job that forms a different CI key, so
```
- name: Cache dependencies
uses: swatinem/rust-cache@v2
with:
save-if: ${{ false }}
```
would not work.
This makes Linux bundling jobs long.
Release Notes:
- N/A
This PR makes Clippy deny all warnings across the workspace.
We now enumerate all of the rules that have violations and temporarily
allow them, with the goal being to drive the list down over time.
On Windows we don't yet use `--deny warnings`, as the Windows build
still has some warnings.
Release Notes:
- N/A
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This practice makes it difficult to locate todo!s in my code when I'm
working. Let's take out the bang if we want to keep doing this.
Release Notes:
- N/A
This PR adjusts the way we cache Cargo dependencies in CI.
We're trying out
[swatinem/rust-cache](https://github.com/swatinem/rust-cache) to see if
it can improve our caching strategy such that we're able to get more
cache hits on PRs.
We'll only write to the cache on `main` in the hopes that it will
mitigate the amount of thrashing of the cache.
Release Notes:
- N/A
We run Linux CI on regular GitHub Action runners, which have ~30GB of
disk space. This is nothing for Rust builds and, due to Cargo.lock
perturbations, we tend to accumulate enough artifacts to fill the disk
entirely since `restore-keys` alowed to keep the cache for different
lockfiles.
Instead, try to invalidate the cache more aggressively (which will cost
us more frequent ~30min Linux CI runs) to see how this will work in
comparison.
Release Notes:
- N/A
Depends on https://github.com/zed-industries/font-kit/pull/2 and
https://github.com/kvark/blade/pull/77
This change enables Blade to be also used on MacOS. It will also make it
easier to use it on Windows.
What works: most of the things. Zed loads as fast and appears equally
responsive to the current renderer.
<img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM"
src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827">
Things missing:
- [x] video streaming. ~~Requires a bit of plumbing on both Blade and
Zed sides, but all fairly straightforward.~~
- verified with a local setup
- [x] resize. ~~Not sure where exactly to hook up the reaction on the
window size change. Once we know where, the fix is one line.~~
- [ ] fine-tune CA Layer
- this isn't a blocker for merging the PR, but it would be a blocker if
we wanted to switch to the new path by default
- [ ] rebase on latest, get the dependency merged (need review/merge of
https://github.com/zed-industries/font-kit/pull/2!)
Update: I implemented resize support as well as "surface" rendering on
the Blade path (which will be useful on Linux/Windows later on). I
haven't tested the latter though - not sure how to get something
streaming. Would appreciate some help! I don't think this should be a
blocker to this PR, anyway.
The only little piece that's missing for the Blade on MacOS path to be
full-featured is fine-tuning the CALayer configuration. Zed does a lot
of careful logic in configuring the layer, such as switching the
"present with transaction" on/off intermittently, which Blade path
doesn't have yet.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR adds a REST API to the collab server for searching and
downloading extensions. Previously, we had implemented this API in
zed.dev directly, but this implementation is better, because we use the
collab database to store the download counts for extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
Runs scheduled CI jobs only on the main repository, not on forks. These
jobs fail on forks and generate unnecessary noise on contributor emails.
Release Notes:
- N/A
After this change we'll be able to push a tag to github to deploy to
collab.
The advantages of this are that there's no longer a separate step to
first
build the image, and then deploy it.
In the future I'd like to make this happen more automatically (maybe as
part of
bump nightly).
Release Notes:
- N/A
We're seeing a bit of nonsense on telemetry. Although the checksum seed
isn't secret per-se, it does make sending nonsense a little more effort.
Release Notes:
- N/A
Those were not installing Rust but configuring it via rustup, and
those configurations were done on `stable` toolchain which is not what we use (see rust-toolchain.toml)
co-authored-by: Piotr <piotr@zed.dev>
<img width="1376" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/681cca85-e1b9-4a99-8363-60c931ba1393">
For any push (or force-push) into a branch, a separate CI workflow is
run.
This is rather worker-consuming, esp. given the fact that GitHub will
wait for the last job to update PR's status.
So cancel every old job for the same branch if it's not `main`.
CI run on `main` might catch a regression brought in by specific PR
merged, so run CI on every commit due to that.
Release Notes:
- N/A
