## 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
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
Although not listed on https://killedbygoogle.com/, the Google
cherry-pick bot was killed some time ago and we now use our own bot for
this. Thus we can safely remove the config here.
Also, fixes the shebang in the cherry-pick script.
Release Notes:
- N/A
## What
Adds `step-security/harden-runner` as the first step of the Linux
Namespace
jobs in `run_tests.yml`, running in audit mode (`egress-policy: audit`).
In
audit mode it records each job's outbound network connections and blocks
nothing — there is no change to what the jobs can do.
Pinned to
`step-security/harden-runner@9af89fc71515a100421586dfdb3dc9c984fbf411`
(v2.19.4); v2.19.0+ is required for Namespace runners. Each run links to
its
per-run insights from the job log.
## Scope
- **Included:** the 13 Linux Namespace jobs in `run_tests.yml`.
- **macOS excluded:** harden-runner's monitoring agent is Linux-only on
Namespace runners — it skips install on Namespace macOS, so it adds no
coverage there and its cleanup step fails.
- **Also not included:** the Windows jobs, the `tests_pass` gate (no
checkout,
no egress to record), and the `extension_tests` reusable-workflow call.
- The shared job builders (`clippy`, `run_platform_tests`,
`check_scripts`,
`orchestrate`) are reused by other workflows, so they take a flag to add
the
step only in the `run_tests` context. `release.yml`,
`release_nightly.yml`,
and `extension_tests.yml` are unchanged.
## How
Edits the workflow DSL under `tooling/xtask/src/tasks/workflows/`; the
YAML is
regenerated with `cargo xtask workflows`.
## Verification
- `cargo xtask workflows` is idempotent — the `check_scripts` parity
check passes.
- `cargo fmt --check` and `actionlint` clean; `zizmor` shows no new
findings vs. baseline.
Release Notes:
- N/A
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
