There are 3 factors:
1. The Preview channel endpoint does not propagate versions with build
identifier (which we oh-so-conveniently store in pre-release field of
semver).
2. Preview build, once fetched, sees it's version *with* build
identifier (as that's baked into the binary).
3. Auto update logic treats versions with pre-release version as less
than versions without pre-release version.
This in turn makes any Preview client see itself as versioned like
0.214.4-123-asdf1234455311, whereas the latest version on the endpoint
is 0.214.4. Thus, the endpoint version is always more recent than the
client version, causing an update loop.
The fix is to ignore build identifier when comparing versions of
non-nightly channels. This should still let us introduce changes to
auto-update behavior in minor releases in the future.
Closes#43584
Release Notes:
- (Preview only): Fixed an update loop with latest Preview update.
The auto update helper already removes these when successful, so these
will always fail in the common case.
Additional replaces a mutable const with a static as otherwise we'll
rebuild the job list on every access
Release Notes:
- N/A *or* Added/Fixed/Improved ...
We've had several outages with a proximate cause of "vercel is
complicated",
and auto-update is considered a critical feature; so lets not use vercel
for
that.
Release Notes:
- Auto Updates (and remote server binaries) are now downloaded via
https://cloud.zed.dev instead of https://zed.dev. As before, these URLs
redirect to the GitHub release for actual downloads.
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
Before this change the active theme and icon theme were retrofitted onto
the ThemeSettings.
Now they're in their own new global (GlobalTheme::theme(cx) and
GlobalTheme::icon_theme(cx))
This lets us remove cx from the settings traits, and tidy up a few other
things along the way.
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 ...
When we refactored settings to not pass JSON blobs around, we ended up
needing
to write *a lot* of code that just merged things (like json merge used
to do).
Use a derive macro to prevent typos in this logic.
Release Notes:
- N/A
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
This adds a test to make sure that the default value of the auto update
setting is always true. We manually re-applied the broken code from last
week, and confirmed that this test fails with that code.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
#37337 Made `AutoUpdateSetting` `FileContent =
AutoUpdateSettingsContent` which caused a deserialization bug to occur
because the field it was wrapping wasn't optional. Thus serde would
deserialize the wrapped type `bool` to its default value `false`
stopping the settings load function from reading the correct default
value from `default.json`
I also added a log message that states when the auto updater struct is
checking for updates to make this easier to test.
Release Notes:
- fix auto update defaulting to false
This PR separates out the associated constant `KEY` from the `Settings`
trait into a new trait `SettingsKey`. This allows for the key trait to
be derived using attributes to specify the path so that the new
`SettingsUi` derive macro can use the same attributes to determine top
level settings paths thereby removing the need to duplicate the path in
both `Settings::KEY` and `#[settings_ui(path = "...")]`
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes #ISSUE
Initially, the `SettingsUi` trait was tied to `Settings`, however, given
that the `Settings::FileContent` type (which may be the same as the type
that implements `Settings`) will be the type that more directly maps to
the JSON structure (and therefore have the documentation, correct field
names (or `serde` rename attributes), etc) it makes more sense to have
the deriving of `SettingsUi` occur on the `FileContent` type rather than
the `Settings` type.
In order for this to work a relatively important change had to be made
to the derive macro, that being that it now "unwraps" options into their
inner type, so a field with type `Option<Foo>` where `Foo: SettingsUi`
will treat the field as if it were just `Foo`, expecting there to be a
default set in `default.json`. This imposes some restrictions on what
`Settings::FileContent` can be as seen in 1e19398 where `FileContent`
itself can't be optional without manually implementing `SettingsUi`, as
well as introducing some risk that if the `FileContent` type has
`serde(default)`, the default value will override the default value from
`default.json` in the UI even though it may differ (but it should!).
A future PR should probably replace the other settings with `FileContent
= Option<T>` (all of which currently have `T == bool`) with wrapper
structs and have `KEY = None` so the further niceties
`derive(SettingsUi)` will provide such as path renaming, custom UI, auto
naming and doc comment extraction can be used.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
## Goal
This PR creates the initial settings ui structure with the primary goal
of making a settings UI that is
- Comprehensive: All settings are available through the UI
- Correct: Easy to understand the underlying JSON file from the UI
- Intuitive
- Easy to implement per setting so that UI is not a hindrance to future
settings changes
### Structure
The overall structure is settings layer -> data layer -> ui layer.
The settings layer is the pre-existing settings definitions, that
implement the `Settings` trait. The data layer is constructed from
settings primarily through the `SettingsUi` trait, and it's associated
derive macro. The data layer tracks the grouping of the settings, the
json path of the settings, and a data representation of how to render
the controls for the setting in the UI, that is either a marker value
for the component to use (avoiding a dependency on the `ui` crate) or a
custom render function.
Abstracting the data layer from the ui layer allows crates depending on
`settings` to implement their own UI without having to add additional UI
dependencies, thus avoiding circular dependencies. In cases where custom
UI is desired, and a creating a custom render function in the same crate
is infeasible due to circular dependencies, the current solution is to
implement a marker for the component in the `settings` crate, and then
handle the rendering of that component in `settings_ui`.
### Foundation
This PR creates a macro and a trait both called `SettingsUi`. The
`SettingsUi` trait is added as a new trait bound on the `Settings`
trait, this allows the type system to guarantee that all settings
implement UI functionality. The macro is used to derived the trait for
most types, and can be modified through attributes for unique cases as
well.
A derive-macro is used to generate the settings UI trait impl, allowing
it the UI generation to be generated from the static information in our
code base (`default.json`, Struct/Enum names, field names, `serde`
attributes, etc). This allows the UI to be auto-generated for the most
part, and ensures consistency across the UI.
#### Immediate Follow ups
- Add a new `SettingsPath` trait that will be a trait bound on
`SettingsUi` and `Settings`
- This trait will replace the `Settings::key` value to enable
`SettingsUi` to infer the json path of it's derived type
- Figure out how to render `Option<T> where T: SettingsUi` correctly
- Handle `serde` attributes in the `SettingsUi` proc macro to correctly
get json path from a type's field and identity
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- Settings can now be configured per operating system with the new
top-level fields: `"macos"`/`"windows"`/`"linux"`. These will override
user level settings, but are lower precedence than _release channel_
settings.
The installer, uninstaller, and the Zed binary files are all signed
using Microsoft’s newly launched Trusted Signing service. For
demonstration purposes, I have used my own account for the signing
process.
For more information about Trusted Signing, you can refer to the
following links:
- [Microsoft Security Blog: Trusted Signing is in Public
Preview](https://techcommunity.microsoft.com/blog/microsoft-security-blog/trusted-signing-is-in-public-preview/4103457)
- [Overview of Azure Trusted
Signing](https://learn.microsoft.com/en-us/azure/trusted-signing/overview)
**TODO:**
- [x] `InnoSetup` script to setup an installer
- [x] Signing process
- [x] `Open with Zed` in right click context menu (by using sparse
package)
- [x] Integrate with `cli`
- [x] Implement `cli` (#25412)
- [x] Pack `cli.exe` into installer
- [x] Implement auto updating (#25734)
- [x] Pack autoupdater helper into installer
- [x] Implement dock menus
- [x] Add `Recent Documents` entries (#26369)
- [x] Make `zed.exe` aware of sigle instance (#25412)
- [x] Properly handle dock menu events (#26010)
- [x] Handle `zed://***` uri
**Materials needed:**
- [ ] Icons
- [ ] App icon for all channels (#9571)
- [ ] Associated file icons, at minimum a default icon
([example](https://github.com/microsoft/vscode/tree/main/resources/win32))
- [ ] Logos for installer wizard
- [ ] Icons for appx
- [x] Code signing
- [x] Secrets: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET,
ACCOUNT_NAME, CERT_PROFILE_NAME
- [x] Other constants: ENDPOINT, Identity Signature (i.e. `CN=Junkui
Zhang, O=Junkui Zhang, L=Wuhan, S=Hubei, C=CN`)
https://github.com/user-attachments/assets/4f1092b4-90fc-4a47-a868-8f2f1a5d8ad8
Release Notes:
- N/A
---------
Co-authored-by: Kate <kate@zed.dev>
Co-authored-by: localcc <work@localcc.cc>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes #ISSUE
Adds a new `documentation` method to actions, that is extracted from doc
comments when using the `actions!` or derive macros.
Additionally, this PR adds doc comments to as many action definitions in
Zed as possible.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Don't immediately show "auto-update failed" errors in the status bar
when launching zed offline or when a periodic auto-update check is
triggered when you are offline. Manual checks (via menu or action) or
errors after the initial version check succeeds (download/extraction
failure) are unchanged.
Supersedes: https://github.com/zed-industries/zed/pull/32643
Release Notes:
- N/A
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
Follow up to #31179
In addition to seeing the version when in the `Click to restart and
update Zed` status, this PR allows us to see the version when in
`Downloading Zed update…` or `Installing Zed update…` status, in a
tooltip, when hovering on the activity indicator.
Will merge after tomorrow's release.
Release Notes:
- Added version information, in a tooltip, when hovering on the activity
indicator for both the download and install status.
This PR simply does a tiny bit of cleanup on some code, where I wasn't
quite happy with the naming and ordering of parameters of the now
`check_if_fetched_version_is_newer` function. There should be no
functional changes here, but I will wait until after tomorrow's release
to merge.
Release Notes:
- N/A
This PR replaces some `update()` calls with either `read()` or
`read_with()` when the `update()` call performed read-only operations on
the entity.
Many more likely exist, will follow-up with more PRs.
Release Notes:
- N/A
This PR brings back https://github.com/zed-industries/zed/pull/30969 and
adds some initial testing.
https://github.com/zed-industries/zed/pull/30969 did indeed allow Zed to
continue doing downloads after downloading one, but it introduced a bug
where Zed would download a new binary every time it polled, even if the
version was the same as the running instance.
This code could use a refactor to allow more / better testing, but this
is a start.
Release Notes:
- N/A
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
Closes https://github.com/zed-industries/zed/issues/8968
This PR addresses the following scenario:
1. User's Zed polls for an update, finds one, and installs it
2. User doesn't immediately restart Zed, a new update is released, and
the previous version of Zed would stop polling (ignoring the new update)
3. User eventually restarts Zed and is immediately prompted to install
another update
With this change, the auto-updater will continue polling for and
installing new versions even after an initial update is found, reducing
update prompts on restart.
---
This PR does not address the following scenario:
1. User's Zed polls for an update, finds one, and installs it
2. Another update is released before the next scheduled polling interval
3. User restarts Zed and is immediately prompted to install the newer
update
Release Notes:
- Improved the auto-updater to continue checking for updates even after
finding and installing an initial update. This reduces situations where
users are prompted to install another update immediately after
restarting from a previous update.
Co-authored-by: Ben Kunkle <Ben.kunkle@gmail.com>
Follow-up of https://github.com/zed-industries/zed/pull/30015
* Restyles the dismiss and close buttons a bit: change the dismiss icon
and add tooltips with the bindings to both
* Allows ESC to clear any status that's in the activity indicator now,
if all notifications are cleared: this won't suppress any further status
additions though, so statuses may resurface later
Release Notes:
- Added a way to clear activity indicator
Things this doesn't currently handle:
- [x] ~testing~
- ~we really need an snapshot test that takes a vscode settings file
with all options that we support, and verifies the zed settings file you
get from importing it, both from an empty starting file or one with lots
of conflicts. that way we can open said vscode settings file in vscode
to ensure that those options all still exist in the future.~
- Discussed this, we don't think this will meaningfully protect us from
future failures, and we will just do this as a manual validation step
before merging this PR. Any imports that have meaningfully complex
translation steps should still be tested.
- [x] confirmation (right now it just clobbers your settings file
silently)
- it'd be really cool if we could show a diff multibuffer of your
current settings with the result of the vscode import and let you pick
"hunks" to keep, but that's probably too much effort for this feature,
especially given that we expect most of the people using it to have an
empty/barebones zed config when they run the import.
- [x] ~UI in the "welcome" page~
- we're planning on redoing our welcome/walkthrough experience anyways,
but in the meantime it'd be nice to conditionally show a button there if
we see a user level vscode config
- we'll add it to the UI when we land the new walkthrough experience,
for now it'll be accessible through the action
- [ ] project-specific settings
- handling translation of `.vscode/settings.json` or `.code-workspace`
settings to `.zed/settings.json` will come in a future PR, along with UI
to prompt the user for those actions when opening a project with local
vscode settings for the first time
- [ ] extension settings
- we probably want to do a best-effort pass of popular extensions like
vim and git lens
- it's also possible to look for installed/enabled extensions with `code
--list-extensions`, but we'd have to maintain some sort of mapping of
those to our settings and/or extensions
- [ ] LSP settings
- these are tricky without access to the json schemas for various
language server extensions. we could probably manage to do translations
for a couple popular languages and avoid solving it in the general case.
- [ ] platform specific settings (`[macos].blah`)
- this is blocked on #16392 which I'm hoping to address soon
- [ ] language specific settings (`[rust].foo`)
- totally doable, just haven't gotten to it yet
~We may want to put this behind some kind of flag and/or not land it
until some of the above issues are addressed, given that we expect
people to only run this importer once there's an incentive to get it
right the first time. Maybe we land it alongside a keymap importer so
you don't have to go through separate imports for those?~
We are gonna land this as-is, all these unchecked items at the bottom
will be addressed in followup PRs, so maybe don't run the importer for
now if you have a large and complex VsCode settings file you'd like to
import.
Release Notes:
- Added a VSCode settings importer, available via a
`zed::ImportVsCodeSettings` action
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
