Reduce the nightly release workflow from six runs per day to two runs
per day, at 02:00 and 14:00 UTC. Update both the workflow generator and
generated workflow.
Validated by regenerating workflows with `cargo xtask workflows`.
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
Based on
https://github.com/zed-industries/zed/pull/64464#issuecomment-5763255028
With `RUST_BACKTRACE=1` set, `anyhow` captures a backtrace for every
error it constructs; on macOS this costs ~30ms per error, on Linux ~µs.
`Project::test` alone hits several such errors during setup
(`canonicalize`/`load` of the non-existent global `tasks.json` and
`debug.json`, worktree creation, buffer open), adding ~0.8s of fixed
cost per test on macOS.
`RUST_LIB_BACKTRACE=0` is checked by std before `RUST_BACKTRACE`, so
panics keep their backtraces while library error captures stop.
Set only on the macOS test jobs (`run_tests.yml`, `release.yml`), since
Linux and Windows pay nothing for the captures and keep the error-origin
backtraces in failure output.
Measured with `cargo nextest run -p editor --lib`: macOS 119s → 72s,
Linux 78s → 76s (noise).
Trade-off on macOS: a failing `.unwrap()` on an `anyhow::Error` in CI
output loses the backtrace of where the error was constructed; the panic
backtrace at the unwrap site is unaffected.
Release Notes:
- N/A
The first dispatched binary-size run failed while compiling `x11`
because the stock `ubuntu-latest` image did not include Zed's Linux
build dependencies. The old Wezel runner incorrectly reported that as a
successful empty run.
Run Zed's existing `./script/linux` setup before the Wezel action,
matching Zed's Linux CI jobs.
Release Notes:
- N/A
Co-authored-by: Amp <amp@ampcode.com>
This PR was created by [Wezel](https://wezel.build) to run assigned
experiments in GitHub Actions. After merging it, add the runner token as
the `WEZEL_RUNNER_TOKEN` repository secret.
Release Notes:
- N/A
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
## Summary
- remove the `incremental-editor` Wezel scenario and its source patch
- build the `zed` binary with the release profile
- track both its original size and the size of a separately stripped
copy
- lock the `exec` and `filesize` foragers and regenerate the experiment
schema
- skip the full Zed test suite when a pull request changes only
`.wezel/**`
## Validation
- `wezel project tool sync`
- `wezel experiment lint`
- `wezel project status`
- smoke-tested the copy-and-strip command against a debug-symbol-bearing
executable on macOS
- `rustfmt --check tooling/xtask/src/tasks/workflows/run_tests.rs`
- `actionlint .github/workflows/run_tests.yml`
- exercised the CI path filter with Wezel-only, mixed, docs-only, and
source-only file sets
The full Zed release build was not run locally.
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
## Summary
Move scheduler Miri tests from 16 vCPUs / 32 GiB to 4 vCPUs / 8 GiB, and
migration checks from 8 vCPUs / 16 GiB to 4 vCPUs / 8 GiB. Reuse the
existing `LINUX_MEDIUM` profile and keep test commands and coverage
unchanged.
September 16 whole-runner CPU samples showed Miri averaging about 1.3
cores with a 2.4-core sampled peak and 2.6 GiB peak RAM; migration
checks averaged 1.2 cores with a 1.8-core sampled peak and 1.3 GiB peak
RAM. These are sampled observations, not a cold-build guarantee.
## Validation
- `cargo xtask workflows`
- `cargo fmt -p xtask -- --check`
- `git diff --check`
- CI on the smaller runners is pending.
## Human review
The root repository rules require the README review notice. The human
author must remove it after review; this PR remains a draft until that
step and CI verification are complete.
Release Notes:
- N/A
Also updates CI to always run this - that way we ensure that disabling
or enabling tests does not become stale at some point and thus can
safely add this.
Release Notes:
- N/A
- [GPUI] N/A
This PR cleans up the repository root a bit, moving some of the less
relevant config files into the `.config` folder and removing unused
ones.
Release Notes:
- N/A
## Summary
Move `check_postgres_and_protobuf_migrations` from the existing 16-vCPU
/ 32-GiB Linux runner to the existing 8-vCPU / 16-GiB runner. The job
handles Git history and Buf compatibility, lint, and formatting checks;
its commands, triggers, and coverage remain unchanged.
This reduces its concurrent CPU and memory allocation by half. Namespace
observations from September 11–14 covered 224 runs, with a typical job
duration of 37 seconds and maximum observed RAM around 1.5 GiB. The p95
of per-run peak CPU usage was about 7.7 cores, so CI runtime on the
smaller profile should be checked rather than assuming identical
performance.
Updated the Rust workflow generator and regenerated the YAML. No other
jobs are changed.
## Validation
- `cargo xtask workflows`
- `cargo fmt -p xtask -- --check`
- `git diff --check`
- Full diff reviewed: two files, only the runner selection changed.
- Actual migration check on the smaller runner awaits CI.
Release Notes:
- N/A
The particular edge case that is covered here is closing a community PR,
then labeling it with an `area:`, and _then_ reopening it.
Release Notes:
- N/A
It's been fun for a while to have the same function calling GitHub API
in every single script, but we're going to have fun in different ways
now.
This one's for you, @MrSubidubi! 🥂
## Testing
I've ran the things that had `--dry-run` locally and nothing blew up,
but the ultimate smoke test will be carried out in production.
---
Release Notes:
- N/A
Fix flacks like
https://github.com/zed-industries/zed/actions/runs/33546906778/job/99987145940?pr=63573
`test_extension_store_with_test_extension` gives the extension builder
`target` as its cache at
`crates/extension_host/src/extension_store_test.rs:801`.
`install_dev_extension` performs a real extension and grammar build at
`crates/extension_host/src/extension_host.rs:1139`.
When `target/wasi-sdk` is absent (e.g. after `target/` cleanup), the
builder downloads and extracts it at
`crates/extension/src/extension_builder.rs:511`.
In the failed run, downloading and extracting the SDK consumed 59
seconds, grammar compilation began at 60 seconds, and the timeout fired
immediately.
Release Notes:
- N/A
- Notify the author when their PR has been in draft state with no new
commits for three weeks
- Close the draft PRs that didn't get updated after one more week
- Re-try the cla-bot check on PRs that are still unsigned after a week
- Close the PRs that are still unsigned after the re-try
## Testing
It works on my machine™
```
python script/github-pr-cleanup.py --dry-run
Checking 713 open pull requests
Dry-run mode: no comments or closures will be made
PR #60885: asking the CLA bot to check again
Would comment on PR #60885:
@cla-bot check
PR #61625: asking the CLA bot to check again
Would comment on PR #61625:
@cla-bot check
PR #57239: warning about a stale draft
Would comment on PR #57239:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #57241: warning about a stale draft
Would comment on PR #57241:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61461: warning about a stale draft
Would comment on PR #61461:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61722: warning about a stale draft
Would comment on PR #61722:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61808: warning about a stale draft
Would comment on PR #61808:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61809: warning about a stale draft
Would comment on PR #61809:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
Cleanup complete: 0 unsigned PR closures, 6 draft warnings, 0 draft closures
```
Release Notes:
- N/A
Also disables them by default because it makes autofixes for the average
case very slow.
Note that this does not yet change anything for the Zippy /autofix
command here.
Release Notes:
- N/A
# Objective
@HalavicH Has been responsible for building out our csv preview feature
and producing plenty of high qualtiy PRs to do so. I'm marking him as a
community champion to recgonize that work and give is PRs higher
priority when it comes to review
Release Notes:
- N/A
Now, this is one of these beautiful cases where GitHubs API ist just so
pleasant to work with: Because PRs are treated as issues, assigning an
assignee to a PR suddenly requires issue write permissions, despite the
issue in question being a PR. Not having that permission resulted in
some missing assignees on zed zippy bumps and failures of the workflows
as seen in
https://github.com/zed-industries/zed/actions/runs/31339736929/job/93311493258.
In comparison, labelling PRs requires PR write permissions as seen in
https://github.com/zed-industries/zed/pull/61525🤡
Beautiful API and a pleasure to work with, 10/10 would recommend.
Release Notes:
- N/A
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`
With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (0500fd9ee9): 13.19s
After: 11.85s (-10.2% speed up)
Each commit contains a separate compilation instructions, and a test in
the final commit.
The main approach is to split coupled crates and replace them with
`zed_actions` and move some shared functionality into `git_ui_core` new,
shared module.
I've also tried to add a test to prevent common pitfalls, but not sure
I'm happy with the end result — can remove it if it looks too synthetic.
Release Notes:
- N/A
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
This should hopefully fix the issue with the version bumps we were
seeing - to bypass push protections, the token seems to need workflow
permissions for some reason as well.
Release Notes:
- N/A
`priority:*` labels in the github repository are becoming `severity:*`,
and `frequency:*` — `reach:*`. This commit will update the slack
notifications for the first responders accordingly.
Also, delete the github-label-issues-to-triage.py one-off script, which
worked with the old label names and is by now too distant in the past to
be useful as reference or anything.
Release Notes:
- N/A
What looks like a single event of applying a few labels is actually
multiple events, and the raciness is racy as we've recently experienced.
One solution would've been adding a “first responders notified” label
for enforcing consistency but issues already have enough labels (and we
could take it off by mistake), so a bot reaction will instead serve as a
marker for any later runs.
So if we're applying multiple labels or changing our mind about, say, an
area label after the notification has already been sent, this should
work fine now, without duplicate notifications.
Release Notes:
- N/A
The `orchestrate` job maps changed directories to root-workspace package
names, and when no mapping was found it fell back to using the raw
directory name as a package. Because `tooling/lints` is a separate
workspace (not a root-workspace member), a change under
`tooling/lints/**` produced the filter `rdeps(lints)`, which `cargo
nextest run --workspace` rejects with "operator didn't match any
packages" — failing `run_tests` for any such PR. This drops that
fallback so an unmapped directory falls through to the existing "no
package changes → run all tests" path instead.
Release Notes:
- N/A
Seeing `script/check-license` fail because we forgot to add a license in
#58496
> Error: tooling/lints does not contain a LICENSE-GPL or LICENSE-APACHE
symlink
Release Notes:
- N/A
