zed/script/bundle-mac

301 lines
12 KiB
Plaintext
Raw Normal View History

Initial Linux nightly bundles upload (#8913) Changes Zed CI to build and upload Linux nightly bundles. * `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based workflows more convenient * renames `run-build-dmg` label into `run-bundling`, also renames a few GH Actions entries to be more generic * make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact. * adds a `*.deb` package building with a couple of caveats, marked with new `TODO linux` entries: 1. `cargo-bundle` is not very flexible, so it generates artifacts with the structure and names that we're unable to alter before/during the generation. For that, a set of extra steps is made by repacking the *.deb package — this is not very portable between different Linux distros, so later one needs to find a way to combine multiple package types in this script. 2. `cargo-bundle` is not able to properly generate the *.msi bundle despite declaring it in the features: https://github.com/burtonageo/cargo-bundle/issues/116 Windows needs to invent its own way of bundling or fix the tool. 3. Both `cli` and `zed` binaries are added into the archive under `/usr/local/bin/` path with their `-$channel` suffix (-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed -> /usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed launcher: ``` ~/work/zed kb/linux-nightly:origin/kb/linux-nightly*​ ❯ dpkg -c target/zed_amd64.deb drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/ -rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly -rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/ -rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/ -rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/ -rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly ``` But the CLI does not work under Linux yet and there's no way to install that CLI from Zed now; Zed binary itself is not able to open `file/location:12:34`-like things and set up the env properly, but is able to start or open a directory. So, this structure can be considered temporary and changed, if needed. 4. Zed Nightly on Linux does not know how to update itself, so all nightly publishing is not picked up automatically. 5. Rust cache from `main` builds does not get shared between CI jobs, due to being run in a different CI job that forms a different CI key, so ``` - name: Cache dependencies uses: swatinem/rust-cache@v2 with: save-if: ${{ false }} ``` would not work. This makes Linux bundling jobs long. Release Notes: - N/A
2024-03-08 00:22:53 +03:00
#!/usr/bin/env bash
Initial Linux nightly bundles upload (#8913) Changes Zed CI to build and upload Linux nightly bundles. * `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based workflows more convenient * renames `run-build-dmg` label into `run-bundling`, also renames a few GH Actions entries to be more generic * make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact. * adds a `*.deb` package building with a couple of caveats, marked with new `TODO linux` entries: 1. `cargo-bundle` is not very flexible, so it generates artifacts with the structure and names that we're unable to alter before/during the generation. For that, a set of extra steps is made by repacking the *.deb package — this is not very portable between different Linux distros, so later one needs to find a way to combine multiple package types in this script. 2. `cargo-bundle` is not able to properly generate the *.msi bundle despite declaring it in the features: https://github.com/burtonageo/cargo-bundle/issues/116 Windows needs to invent its own way of bundling or fix the tool. 3. Both `cli` and `zed` binaries are added into the archive under `/usr/local/bin/` path with their `-$channel` suffix (-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed -> /usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed launcher: ``` ~/work/zed kb/linux-nightly:origin/kb/linux-nightly*​ ❯ dpkg -c target/zed_amd64.deb drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/ -rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly -rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/ -rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/ -rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/ -rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly ``` But the CLI does not work under Linux yet and there's no way to install that CLI from Zed now; Zed binary itself is not able to open `file/location:12:34`-like things and set up the env properly, but is able to start or open a directory. So, this structure can be considered temporary and changed, if needed. 4. Zed Nightly on Linux does not know how to update itself, so all nightly publishing is not picked up automatically. 5. Rust cache from `main` builds does not get shared between CI jobs, due to being run in a different CI job that forms a different CI key, so ``` - name: Cache dependencies uses: swatinem/rust-cache@v2 with: save-if: ${{ false }} ``` would not work. This makes Linux bundling jobs long. Release Notes: - N/A
2024-03-08 00:22:53 +03:00
set -euxo pipefail
build_flag="--release"
target_dir="release"
open_result=false
local_arch=false
local_only=false
overwrite_local_app=false
bundle_name=""
2023-11-18 04:44:11 +03:00
zed_crate="zed"
2023-11-20 21:34:22 +03:00
binary_name="Zed"
# This must match the team in the provisioning profile.
2023-11-06 20:37:35 +03:00
APPLE_NOTORIZATION_TEAM="MQ55VZLNZQ"
# Function for displaying help info
help_info() {
echo "
Usage: ${0##*/} [options] [bundle_name]
Initial Linux nightly bundles upload (#8913) Changes Zed CI to build and upload Linux nightly bundles. * `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based workflows more convenient * renames `run-build-dmg` label into `run-bundling`, also renames a few GH Actions entries to be more generic * make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact. * adds a `*.deb` package building with a couple of caveats, marked with new `TODO linux` entries: 1. `cargo-bundle` is not very flexible, so it generates artifacts with the structure and names that we're unable to alter before/during the generation. For that, a set of extra steps is made by repacking the *.deb package — this is not very portable between different Linux distros, so later one needs to find a way to combine multiple package types in this script. 2. `cargo-bundle` is not able to properly generate the *.msi bundle despite declaring it in the features: https://github.com/burtonageo/cargo-bundle/issues/116 Windows needs to invent its own way of bundling or fix the tool. 3. Both `cli` and `zed` binaries are added into the archive under `/usr/local/bin/` path with their `-$channel` suffix (-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed -> /usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed launcher: ``` ~/work/zed kb/linux-nightly:origin/kb/linux-nightly*​ ❯ dpkg -c target/zed_amd64.deb drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/ -rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly -rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/ -rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/ -rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/ -rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly ``` But the CLI does not work under Linux yet and there's no way to install that CLI from Zed now; Zed binary itself is not able to open `file/location:12:34`-like things and set up the env properly, but is able to start or open a directory. So, this structure can be considered temporary and changed, if needed. 4. Zed Nightly on Linux does not know how to update itself, so all nightly publishing is not picked up automatically. 5. Rust cache from `main` builds does not get shared between CI jobs, due to being run in a different CI job that forms a different CI key, so ``` - name: Cache dependencies uses: swatinem/rust-cache@v2 with: save-if: ${{ false }} ``` would not work. This makes Linux bundling jobs long. Release Notes: - N/A
2024-03-08 00:22:53 +03:00
Build the application bundle for macOS.
Options:
-d Compile in debug mode
-l Compile for local architecture and copy bundle to /Applications, implies -d.
-o Open the resulting DMG or the app itself in local mode.
-f Overwrite the local app bundle if it exists.
-h Display this help and exit.
"
}
function uploadDsym
{
SPACE="zed-debug-symbols"
REGION="nyc3"
file_to_upload="$1"
file_name="$2"
date=$(date +"%a, %d %b %Y %T %z")
acl="x-amz-acl:public-read"
content_type="application/octet-stream"
storage_type="x-amz-storage-class:STANDARD"
string="PUT\n\n${content_type}\n${date}\n${acl}\n${storage_type}\n/${SPACE}/${file_name}"
signature=$(echo -en "${string}" | openssl sha1 -hmac "${DIGITALOCEAN_SPACES_SECRET_KEY}" -binary | base64)
curl --fail -vv -s -X PUT -T "$file_to_upload" \
-H "Host: ${SPACE}.${REGION}.digitaloceanspaces.com" \
-H "Date: $date" \
-H "Content-Type: $content_type" \
-H "$storage_type" \
-H "$acl" \
-H "Authorization: AWS ${DIGITALOCEAN_SPACES_ACCESS_KEY}:$signature" \
"https://${SPACE}.${REGION}.digitaloceanspaces.com/${file_name}"
}
while getopts 'dlfoh' flag
do
case "${flag}" in
o) open_result=true;;
d)
export CARGO_INCREMENTAL=true
export CARGO_BUNDLE_SKIP_BUILD=true
build_flag="";
target_dir="debug"
;;
l)
export CARGO_INCREMENTAL=true
export CARGO_BUNDLE_SKIP_BUILD=true
build_flag=""
local_arch=true
local_only=true
target_dir="debug"
;;
f) overwrite_local_app=true;;
h)
help_info
exit 0
;;
esac
done
shift $((OPTIND-1))
Initial Linux nightly bundles upload (#8913) Changes Zed CI to build and upload Linux nightly bundles. * `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based workflows more convenient * renames `run-build-dmg` label into `run-bundling`, also renames a few GH Actions entries to be more generic * make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact. * adds a `*.deb` package building with a couple of caveats, marked with new `TODO linux` entries: 1. `cargo-bundle` is not very flexible, so it generates artifacts with the structure and names that we're unable to alter before/during the generation. For that, a set of extra steps is made by repacking the *.deb package — this is not very portable between different Linux distros, so later one needs to find a way to combine multiple package types in this script. 2. `cargo-bundle` is not able to properly generate the *.msi bundle despite declaring it in the features: https://github.com/burtonageo/cargo-bundle/issues/116 Windows needs to invent its own way of bundling or fix the tool. 3. Both `cli` and `zed` binaries are added into the archive under `/usr/local/bin/` path with their `-$channel` suffix (-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed -> /usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed launcher: ``` ~/work/zed kb/linux-nightly:origin/kb/linux-nightly*​ ❯ dpkg -c target/zed_amd64.deb drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/ -rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly -rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/ -rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/ -rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/ -rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly ``` But the CLI does not work under Linux yet and there's no way to install that CLI from Zed now; Zed binary itself is not able to open `file/location:12:34`-like things and set up the env properly, but is able to start or open a directory. So, this structure can be considered temporary and changed, if needed. 4. Zed Nightly on Linux does not know how to update itself, so all nightly publishing is not picked up automatically. 5. Rust cache from `main` builds does not get shared between CI jobs, due to being run in a different CI job that forms a different CI key, so ``` - name: Cache dependencies uses: swatinem/rust-cache@v2 with: save-if: ${{ false }} ``` would not work. This makes Linux bundling jobs long. Release Notes: - N/A
2024-03-08 00:22:53 +03:00
if [[ $# -gt 0 ]]; then
if [ "$1" ]; then
bundle_name=$1
fi
fi
export ZED_BUNDLE=true
export MACOSX_DEPLOYMENT_TARGET=10.15.7
cargo_bundle_version=$(cargo -q bundle --help 2>&1 | head -n 1 || echo "")
if [ "$cargo_bundle_version" != "cargo-bundle v0.6.0-zed" ]; then
cargo install cargo-bundle --git https://github.com/zed-industries/cargo-bundle.git --branch zed-deploy
fi
# Deal with versions of macOS that don't include libstdc++ headers
export CXXFLAGS="-stdlib=libc++"
version_info=$(rustc --version --verbose)
host_line=$(echo "$version_info" | grep host)
local_target_triple=${host_line#*: }
if [ "$local_arch" = true ]; then
echo "Building for local target only."
2023-11-18 04:44:11 +03:00
cargo build ${build_flag} --package ${zed_crate}
cargo build ${build_flag} --package cli
else
echo "Compiling zed binaries"
2023-11-18 04:44:11 +03:00
cargo build ${build_flag} --package ${zed_crate} --package cli --target aarch64-apple-darwin --target x86_64-apple-darwin
fi
echo "Creating application bundle"
pushd crates/zed
channel=$(<RELEASE_CHANNEL)
2023-11-18 04:44:11 +03:00
popd
pushd crates/${zed_crate}
cp Cargo.toml Cargo.toml.backup
sed \
-i .backup \
"s/package.metadata.bundle-${channel}/package.metadata.bundle/" \
Cargo.toml
if [ "$local_arch" = true ]; then
app_path=$(cargo bundle ${build_flag} --select-workspace-root | xargs)
else
app_path=$(cargo bundle ${build_flag} --target x86_64-apple-darwin --select-workspace-root | xargs)
fi
mv Cargo.toml.backup Cargo.toml
popd
echo "Bundled ${app_path}"
if [ "$local_arch" = false ]; then
echo "Uploading dSYMs"
Enable Blade on MacOS via "macos-blade" feature (#7669) Depends on https://github.com/zed-industries/font-kit/pull/2 and https://github.com/kvark/blade/pull/77 This change enables Blade to be also used on MacOS. It will also make it easier to use it on Windows. What works: most of the things. Zed loads as fast and appears equally responsive to the current renderer. <img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM" src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827"> Things missing: - [x] video streaming. ~~Requires a bit of plumbing on both Blade and Zed sides, but all fairly straightforward.~~ - verified with a local setup - [x] resize. ~~Not sure where exactly to hook up the reaction on the window size change. Once we know where, the fix is one line.~~ - [ ] fine-tune CA Layer - this isn't a blocker for merging the PR, but it would be a blocker if we wanted to switch to the new path by default - [ ] rebase on latest, get the dependency merged (need review/merge of https://github.com/zed-industries/font-kit/pull/2!) Update: I implemented resize support as well as "surface" rendering on the Blade path (which will be useful on Linux/Windows later on). I haven't tested the latter though - not sure how to get something streaming. Would appreciate some help! I don't think this should be a blocker to this PR, anyway. The only little piece that's missing for the Blade on MacOS path to be full-featured is fine-tuning the CALayer configuration. Zed does a lot of careful logic in configuring the layer, such as switching the "present with transaction" on/off intermittently, which Blade path doesn't have yet. Release Notes: - N/A --------- Co-authored-by: Mikayla <mikayla@zed.dev>
2024-02-17 00:39:40 +03:00
dsymutil --flat target/aarch64-apple-darwin/${target_dir}/Zed
dsymutil --flat target/x86_64-apple-darwin/${target_dir}/Zed
version="$(cargo metadata --no-deps --manifest-path crates/zed/Cargo.toml --offline --format-version=1 | jq -r '.packages | map(select(.name == "zed"))[0].version')"
if [ "$channel" == "nightly" ]; then
version="$version-$(git rev-parse --short HEAD)"
fi
echo "Removing existing gzipped dSYMs"
Enable Blade on MacOS via "macos-blade" feature (#7669) Depends on https://github.com/zed-industries/font-kit/pull/2 and https://github.com/kvark/blade/pull/77 This change enables Blade to be also used on MacOS. It will also make it easier to use it on Windows. What works: most of the things. Zed loads as fast and appears equally responsive to the current renderer. <img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM" src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827"> Things missing: - [x] video streaming. ~~Requires a bit of plumbing on both Blade and Zed sides, but all fairly straightforward.~~ - verified with a local setup - [x] resize. ~~Not sure where exactly to hook up the reaction on the window size change. Once we know where, the fix is one line.~~ - [ ] fine-tune CA Layer - this isn't a blocker for merging the PR, but it would be a blocker if we wanted to switch to the new path by default - [ ] rebase on latest, get the dependency merged (need review/merge of https://github.com/zed-industries/font-kit/pull/2!) Update: I implemented resize support as well as "surface" rendering on the Blade path (which will be useful on Linux/Windows later on). I haven't tested the latter though - not sure how to get something streaming. Would appreciate some help! I don't think this should be a blocker to this PR, anyway. The only little piece that's missing for the Blade on MacOS path to be full-featured is fine-tuning the CALayer configuration. Zed does a lot of careful logic in configuring the layer, such as switching the "present with transaction" on/off intermittently, which Blade path doesn't have yet. Release Notes: - N/A --------- Co-authored-by: Mikayla <mikayla@zed.dev>
2024-02-17 00:39:40 +03:00
rm -f target/aarch64-apple-darwin/${target_dir}/Zed.dwarf.gz
rm -f target/x86_64-apple-darwin/${target_dir}/Zed.dwarf.gz
echo "Gzipping dSYMs"
Enable Blade on MacOS via "macos-blade" feature (#7669) Depends on https://github.com/zed-industries/font-kit/pull/2 and https://github.com/kvark/blade/pull/77 This change enables Blade to be also used on MacOS. It will also make it easier to use it on Windows. What works: most of the things. Zed loads as fast and appears equally responsive to the current renderer. <img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM" src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827"> Things missing: - [x] video streaming. ~~Requires a bit of plumbing on both Blade and Zed sides, but all fairly straightforward.~~ - verified with a local setup - [x] resize. ~~Not sure where exactly to hook up the reaction on the window size change. Once we know where, the fix is one line.~~ - [ ] fine-tune CA Layer - this isn't a blocker for merging the PR, but it would be a blocker if we wanted to switch to the new path by default - [ ] rebase on latest, get the dependency merged (need review/merge of https://github.com/zed-industries/font-kit/pull/2!) Update: I implemented resize support as well as "surface" rendering on the Blade path (which will be useful on Linux/Windows later on). I haven't tested the latter though - not sure how to get something streaming. Would appreciate some help! I don't think this should be a blocker to this PR, anyway. The only little piece that's missing for the Blade on MacOS path to be full-featured is fine-tuning the CALayer configuration. Zed does a lot of careful logic in configuring the layer, such as switching the "present with transaction" on/off intermittently, which Blade path doesn't have yet. Release Notes: - N/A --------- Co-authored-by: Mikayla <mikayla@zed.dev>
2024-02-17 00:39:40 +03:00
gzip target/aarch64-apple-darwin/${target_dir}/Zed.dwarf
gzip target/x86_64-apple-darwin/${target_dir}/Zed.dwarf
echo "Uploading dSYMs"
Enable Blade on MacOS via "macos-blade" feature (#7669) Depends on https://github.com/zed-industries/font-kit/pull/2 and https://github.com/kvark/blade/pull/77 This change enables Blade to be also used on MacOS. It will also make it easier to use it on Windows. What works: most of the things. Zed loads as fast and appears equally responsive to the current renderer. <img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM" src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827"> Things missing: - [x] video streaming. ~~Requires a bit of plumbing on both Blade and Zed sides, but all fairly straightforward.~~ - verified with a local setup - [x] resize. ~~Not sure where exactly to hook up the reaction on the window size change. Once we know where, the fix is one line.~~ - [ ] fine-tune CA Layer - this isn't a blocker for merging the PR, but it would be a blocker if we wanted to switch to the new path by default - [ ] rebase on latest, get the dependency merged (need review/merge of https://github.com/zed-industries/font-kit/pull/2!) Update: I implemented resize support as well as "surface" rendering on the Blade path (which will be useful on Linux/Windows later on). I haven't tested the latter though - not sure how to get something streaming. Would appreciate some help! I don't think this should be a blocker to this PR, anyway. The only little piece that's missing for the Blade on MacOS path to be full-featured is fine-tuning the CALayer configuration. Zed does a lot of careful logic in configuring the layer, such as switching the "present with transaction" on/off intermittently, which Blade path doesn't have yet. Release Notes: - N/A --------- Co-authored-by: Mikayla <mikayla@zed.dev>
2024-02-17 00:39:40 +03:00
uploadDsym target/aarch64-apple-darwin/${target_dir}/Zed.dwarf.gz "$channel/Zed-$version-aarch64-apple-darwin.dwarf.gz"
uploadDsym target/x86_64-apple-darwin/${target_dir}/Zed.dwarf.gz "$channel/Zed-$version-x86_64-apple-darwin.dwarf.gz"
echo "Creating fat binaries"
lipo \
-create \
2023-11-20 21:34:22 +03:00
target/{x86_64-apple-darwin,aarch64-apple-darwin}/${target_dir}/${binary_name} \
-output \
2023-11-18 21:46:35 +03:00
"${app_path}/Contents/MacOS/${zed_crate}"
lipo \
-create \
target/{x86_64-apple-darwin,aarch64-apple-darwin}/${target_dir}/cli \
-output \
"${app_path}/Contents/MacOS/cli"
fi
echo "Copying WebRTC.framework into the frameworks folder"
mkdir "${app_path}/Contents/Frameworks"
if [ "$local_arch" = false ]; then
cp -R target/${local_target_triple}/${target_dir}/WebRTC.framework "${app_path}/Contents/Frameworks/"
else
cp -R target/${target_dir}/WebRTC.framework "${app_path}/Contents/Frameworks/"
cp -R target/${target_dir}/cli "${app_path}/Contents/MacOS/"
fi
2024-01-10 03:14:54 +03:00
# Note: The app identifier for our development builds is the same as the app identifier for nightly.
2023-11-18 04:44:11 +03:00
cp crates/${zed_crate}/contents/$channel/embedded.provisionprofile "${app_path}/Contents/"
if [[ -n "${MACOS_CERTIFICATE:-}" && -n "${MACOS_CERTIFICATE_PASSWORD:-}" && -n "${APPLE_NOTARIZATION_USERNAME:-}" && -n "${APPLE_NOTARIZATION_PASSWORD:-}" ]]; then
echo "Signing bundle with Apple-issued certificate"
security create-keychain -p "$MACOS_CERTIFICATE_PASSWORD" zed.keychain || echo ""
2021-09-11 07:51:45 +03:00
security default-keychain -s zed.keychain
security unlock-keychain -p "$MACOS_CERTIFICATE_PASSWORD" zed.keychain
echo "$MACOS_CERTIFICATE" | base64 --decode > /tmp/zed-certificate.p12
security import /tmp/zed-certificate.p12 -k zed.keychain -P "$MACOS_CERTIFICATE_PASSWORD" -T /usr/bin/codesign
rm /tmp/zed-certificate.p12
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$MACOS_CERTIFICATE_PASSWORD" zed.keychain
2023-10-12 00:17:46 +03:00
# sequence of codesign commands modeled after this example: https://developer.apple.com/forums/thread/701514
2023-10-26 10:58:35 +03:00
/usr/bin/codesign --deep --force --timestamp --sign "Zed Industries, Inc." "${app_path}/Contents/Frameworks/WebRTC.framework" -v
/usr/bin/codesign --deep --force --timestamp --options runtime --sign "Zed Industries, Inc." "${app_path}/Contents/MacOS/cli" -v
2023-11-18 05:27:11 +03:00
/usr/bin/codesign --deep --force --timestamp --options runtime --entitlements crates/${zed_crate}/resources/zed.entitlements --sign "Zed Industries, Inc." "${app_path}/Contents/MacOS/${zed_crate}" -v
2023-11-18 04:44:11 +03:00
/usr/bin/codesign --force --timestamp --options runtime --entitlements crates/${zed_crate}/resources/zed.entitlements --sign "Zed Industries, Inc." "${app_path}" -v
2023-10-12 00:17:46 +03:00
2021-09-11 08:11:22 +03:00
security default-keychain -s login.keychain
else
echo "One or more of the following variables are missing: MACOS_CERTIFICATE, MACOS_CERTIFICATE_PASSWORD, APPLE_NOTARIZATION_USERNAME, APPLE_NOTARIZATION_PASSWORD"
if [[ "$local_only" = false ]]; then
echo "To create a self-signed local build use ./scripts/build.sh -ldf"
exit 1
fi
echo "====== WARNING ======"
echo "This bundle is being signed without all entitlements, some features (e.g. universal links) will not work"
echo "====== WARNING ======"
# NOTE: if you need to test universal links you have a few paths forward:
Initial Linux nightly bundles upload (#8913) Changes Zed CI to build and upload Linux nightly bundles. * `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based workflows more convenient * renames `run-build-dmg` label into `run-bundling`, also renames a few GH Actions entries to be more generic * make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact. * adds a `*.deb` package building with a couple of caveats, marked with new `TODO linux` entries: 1. `cargo-bundle` is not very flexible, so it generates artifacts with the structure and names that we're unable to alter before/during the generation. For that, a set of extra steps is made by repacking the *.deb package — this is not very portable between different Linux distros, so later one needs to find a way to combine multiple package types in this script. 2. `cargo-bundle` is not able to properly generate the *.msi bundle despite declaring it in the features: https://github.com/burtonageo/cargo-bundle/issues/116 Windows needs to invent its own way of bundling or fix the tool. 3. Both `cli` and `zed` binaries are added into the archive under `/usr/local/bin/` path with their `-$channel` suffix (-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed -> /usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed launcher: ``` ~/work/zed kb/linux-nightly:origin/kb/linux-nightly*​ ❯ dpkg -c target/zed_amd64.deb drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/ -rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly -rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/ -rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/ -rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/ drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/ -rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly ``` But the CLI does not work under Linux yet and there's no way to install that CLI from Zed now; Zed binary itself is not able to open `file/location:12:34`-like things and set up the env properly, but is able to start or open a directory. So, this structure can be considered temporary and changed, if needed. 4. Zed Nightly on Linux does not know how to update itself, so all nightly publishing is not picked up automatically. 5. Rust cache from `main` builds does not get shared between CI jobs, due to being run in a different CI job that forms a different CI key, so ``` - name: Cache dependencies uses: swatinem/rust-cache@v2 with: save-if: ${{ false }} ``` would not work. This makes Linux bundling jobs long. Release Notes: - N/A
2024-03-08 00:22:53 +03:00
# - create a PR and tag it with the `run-bundling` label, and download the .dmg file from there.
# - get a signing key for the MQ55VZLNZQ team from Nathan.
# - create your own signing key, and update references to MQ55VZLNZQ to your own team ID
# then comment out this line.
2023-11-18 04:44:11 +03:00
cat crates/${zed_crate}/resources/zed.entitlements | sed '/com.apple.developer.associated-domains/,+1d' > "${app_path}/Contents/Resources/zed.entitlements"
codesign --force --deep --entitlements "${app_path}/Contents/Resources/zed.entitlements" --sign ${MACOS_SIGNING_KEY:- -} "${app_path}" -v
fi
if [[ "$target_dir" = "debug" && "$local_only" = false ]]; then
if [ "$open_result" = true ]; then
open "$app_path"
else
echo "Created application bundle:"
echo "$app_path"
fi
exit 0
fi
# If bundle_name is not set or empty, use the basename of $app_path
if [ -z "$bundle_name" ]; then
bundle_name=$(basename "$app_path")
else
# If bundle_name doesn't end in .app, append it
if [[ "$bundle_name" != *.app ]]; then
bundle_name="$bundle_name.app"
fi
fi
if [ "$local_only" = true ]; then
if [ "$overwrite_local_app" = true ]; then
rm -rf "/Applications/$bundle_name"
fi
mv "$app_path" "/Applications/$bundle_name"
if [ "$open_result" = true ]; then
open "/Applications/$bundle_name"
else
echo "Installed application bundle:"
echo "/Applications/$bundle_name"
fi
else
dmg_target_directory="target/${target_dir}"
dmg_source_directory="${dmg_target_directory}/dmg"
dmg_file_path="${dmg_target_directory}/Zed.dmg"
xcode_bin_dir_path="$(xcode-select -p)/usr/bin"
rm -rf ${dmg_source_directory}
mkdir -p ${dmg_source_directory}
mv "${app_path}" "${dmg_source_directory}"
if [[ -n $MACOS_CERTIFICATE && -n $MACOS_CERTIFICATE_PASSWORD && -n $APPLE_NOTARIZATION_USERNAME && -n $APPLE_NOTARIZATION_PASSWORD ]]; then
echo "Creating temporary DMG at ${dmg_file_path} using ${dmg_source_directory} to notarize app bundle"
hdiutil create -volname Zed -srcfolder "${dmg_source_directory}" -ov -format UDZO "${dmg_file_path}"
echo "Notarizing DMG with Apple"
"${xcode_bin_dir_path}/notarytool" submit --wait --apple-id "$APPLE_NOTARIZATION_USERNAME" --password "$APPLE_NOTARIZATION_PASSWORD" --team-id "$APPLE_NOTORIZATION_TEAM" "${dmg_file_path}"
echo "Removing temporary DMG (used only for notarization)"
rm "${dmg_file_path}"
echo "Stapling notarization ticket to ${dmg_source_directory}/${bundle_name}"
"${xcode_bin_dir_path}/stapler" staple "${dmg_source_directory}/${bundle_name}"
fi
echo "Adding symlink to /Applications to ${dmg_source_directory}"
ln -s /Applications ${dmg_source_directory}
echo "Creating final DMG at ${dmg_file_path} using ${dmg_source_directory}"
hdiutil create -volname Zed -srcfolder "${dmg_source_directory}" -ov -format UDZO "${dmg_file_path}"
# If someone runs this bundle script locally, a symlink will be placed in `dmg_source_directory`.
# This symlink causes CPU issues with Zed if the Zed codebase is the project being worked on, so we simply remove it for now.
echo "Removing symlink to /Applications from ${dmg_source_directory}"
rm ${dmg_source_directory}/Applications
echo "Adding license agreement to DMG"
npm install --global dmg-license minimist
dmg-license script/eula/eula.json "${dmg_file_path}"
if [[ -n $MACOS_CERTIFICATE && -n $MACOS_CERTIFICATE_PASSWORD && -n $APPLE_NOTARIZATION_USERNAME && -n $APPLE_NOTARIZATION_PASSWORD ]]; then
echo "Notarizing DMG with Apple"
"${xcode_bin_dir_path}/notarytool" submit --wait --apple-id "$APPLE_NOTARIZATION_USERNAME" --password "$APPLE_NOTARIZATION_PASSWORD" --team-id "$APPLE_NOTORIZATION_TEAM" "${dmg_file_path}"
"${xcode_bin_dir_path}/stapler" staple "${dmg_file_path}"
fi
2021-09-11 08:11:22 +03:00
if [ "$open_result" = true ]; then
open $dmg_target_directory
fi
fi