* cli: use terrapin for cli builds
* update rust to 1.70 to allow ado artifacts feed on windows
* apparently manaul cargo login is required
* use msrustup
* rustup is no longer user
* update to 1.73
* add rust oss install
- Remove the `prepare` script entirely
- Variables are now populated from the product.json during build. Most
variables are mapped automatically, with some special handling in a
few cases. `build.rs` is now much more self-contained.
- Look for the `product.overrides.json` for vscode developers instead of
looking for a peer `vscode-distro` folder
Fixes#178691
* build: don't apply cli 'patches' for merge check
This also needed modules installed. But with the new toml patches, the 'merge' will never fail outright, so there's no need to do a separate merge check for it imo
* reduce duplication in pipelines, cache node_modules
* cli: store cli in user data dir, separate per quality
Fixes#181017
On first run, the `~/.vscode-cli` will be migrated inside the user data dir of the currently running quality.
* use create_dir_all instead
* clippy fixes
* Simplify distro
Also a ton of drive-by fixing around builds:
- simplified many oneliners
- fixed missing custom npm registry call setups
- remove unnecessary and duplicate work during builds
- many many fixes
A fully-functioning CLI with tunnel capabilities requires product-specific
configuration that is not included in the OSS. This change has the CLI's build
script automatically look for a peer `vscode-distro` folder and, in a debug
build, set its build variables based on that.
It also works to set correct variables if vscode-distro is not found, based on
the OSS product.json (though this is not sufficient to run a fully fledged
tunnel.)
systemd, like most 'modern' linux components, has a nice dbus API. This uses
that API to register the tunnel as a service of the calling user.
The dbus dependency is temporarily duplicated, until secret-service 3 is
released, where they update to the latest version (should be a week or two).
For https://github.com/microsoft/vscode-cli/issues/367. Next up, macOS,
then it's done :)
The standalone CLI should detect and fall back to using and
system-installed VS Code instance, rather than trying to download zips
and manage its own VS Code instances.
There are three approaches used for discovery:
- On Windows, we can easily and quickly read the register to find
installed versions based on their app ID.
- On macOS, we initially look in `/Applications` and fall back to the
slow `system_profiler` command to list app .app's if that fails.
- On Linux, we just look in the PATH. I believe all Linux installers
(snap, dep, rpm) automatically add VS Code to the user's PATH.
Failing this, the user can also manually specify their installation dir,
using the command `code version use stable --install-dir /path/to/vscode`.
Fixes#164159
