This starts the work on a workflow that can be invoked in extension CI
to test changes on extension repositories.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This fixes various issues where rustfmt failed to format code due to too
long strings, most of which I stumbled across over the last week and
some additonal ones I searched for whilst fixing the others.
Release Notes:
- N/A
This hopefully resolves the lingering test failures on linux,
but also adds some logging just in case this isn't the problem...
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Our new linux runners don't have powershell installed which causes the
`release-winget` job to fail. This simply runs that step on windows
instead.
Release Notes:
- N/A
One of the reasons we didn't spot that we were missing the telemetry env
vars for the production builds was that nightly (which was working) had
its own set of build steps. This re-uses those and pushes the env vars
down from the workflow to the job.
It also fixes nightly releases to upload all-in-one go so that all
platforms update in sync.
Closes#41655
Release Notes:
- N/A
I just pulled and ran a local build via `script/bundle-mac -l -i` but
found that the resulting bundle wasn't installed as expected. (me:
"ToggleAllDocks!! Wait! Where is it?!") Looking into, it looks like the
`-l` flag was removed in #41392, leaving the `$local_only` var orphaned,
which then left the `-i/$local_install` flag unreachable. I suspect that
this was unintentional, so this PR re-adds the `-l/$local_only` flag to
`script/bundle-mac`.
I ran the build again and confirmed that local install seemed to work as
expected. (ie "ToggleAllDocks!! 🎉")
While here, I also removed the last reference to `$local_arch`, because
all other references to that were removed in #41392.
/cc @osiewicz
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Reverts zed-industries/zed#41384
The branch-protection rules work much better when there is a Job that
runs every time and can be depended on to pass, we no longer have this.
Release Notes:
- N/A
Follow up for: #41304
Splits CI tests (cherry-picks and PRs only for now) into separate
workflows using `gh-workflow`. Includes a couple restructures to
- run more things in parallel
- remove our previous shell script based checking to filter tests based
on files changed, instead using the builtin `paths:` workflow filters
Splitting the docs/style/rust tests & checks into separate workflows
means we lose the complete summary showing all the tests in one view,
but it's possible to re-add in the future if we go back to checking what
files changed ourselves or always run everything.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad <conrad@zed.dev>
To help make our GitHub Actions easier to understand, we're planning to
split the existing `ci.yml` into three separate workflows:
* run_bundling.yml (this PR)
* run_tests.yml
* make_release.yml
To avoid the duplication that this might otherwise cause, we're planning
to write the workflows with gh-workflow, and use rust instead of
encoding logic in YAML conditions.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
This moves some of the changes made in
https://github.com/zed-industries/zed/pull/39543 to the `publish_gpui`
script.
This PR also updates that script to use `gpui_` instead of `zed-` (where
possible)
Release Notes:
- N/A
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
This PR makes it so `workspace-hack` is ignored by `cargo xtask
package-conformity` when looking for non-workspace dependencies.
Also added `zed_extension_api` to the exclude list.
Release Notes:
- N/A
