Add Zed installation tasks

[kenorb]

Summary by Sourcery

Add optional Zed editor installation to the Linux setup playbook, including download, installation, desktop integration, and cleanup steps controlled by a new variable.

New Features:

• Introduce Zed installation task file to install the editor for Linux users when enabled.
• Add Zed installation toggle to the example variables configuration to control whether Zed is installed.

Enhancements:

• Integrate Zed installation tasks into the main Linux setup playbook behind a conditional flag, aligning it with other optional tool installations.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8c20f351-9649-4c3b-9186-afb6761417a3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

This PR adds optional Ansible tasks to install the Zed editor on Linux, wiring them into the existing setup playbook and example variables file, and implements an idempotent installation flow that downloads, unpacks, links, and registers Zed as a desktop application when enabled.

File-Level Changes

Change	Details	Files
Wire Zed installation into the main Linux setup playbook as an optional task set controlled by a variable.	Add an import_tasks entry for Zed in the Linux setup playbook with conditional execution based on a zed variable. Tag the Zed import with zed and install to integrate into existing tagging conventions.	.ansible/playbooks/setup-linux.yml
Expose a configuration toggle for Zed installation in the example variables file.	Add a zed boolean variable to variables-example.yml to demonstrate how to enable Zed installation.	.ansible/variables-example.yml
Introduce a dedicated Zed installation task file that performs an idempotent user-local install and desktop integration.	Check for an existing Zed binary in ~/.local/bin and short-circuit most tasks if present. Create a temporary directory for downloading the Zed tarball only when Zed is not yet installed. Set installation facts for Zed channel, version, and architecture with architecture mapping between aarch64/arm64 and x86_64. Download the appropriate Zed tarball from cloud.zed.dev into the temporary directory when needed. Prepare ~/.local/zed.app and ensure ~/.local/bin and ~/.local/share/applications exist. Unarchive the downloaded tarball into ~/.local/ to install the Zed app directory. Create a symlink for the Zed binary into ~/.local/bin/zed. Copy the Zed .desktop file into the local applications directory and tolerate failures with ignore_errors. Patch the desktop file to use an absolute icon path and Exec path pointing to the installed Zed binary, ignoring errors if the file is missing. Remove the temporary download directory after installation if it was created.	.ansible/playbooks/tasks/zed.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[github-actions]

⛔ Workflow Failures Detected

The following job errors and annotations were found:

• Check / check / Link Checker at .github:161: Process completed with exit code 2.
• Check / check / Link Checker at .github:160: Summary report available at: https://github.com/kenorb/dotfiles/actions/runs/31259637187#summary-93108329859
• Check / check / Pre-commit at .github:117: Process completed with exit code 1.
• Check / check / Pre-commit at .ansible/variables-example.yml:174: Line too long (125 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/zed.yml:72: Use failed_when and specify error conditions instead of using ignore_errors.
• Check / check / Pre-commit at .ansible/playbooks/tasks/zed.yml:65: Use failed_when and specify error conditions instead of using ignore_errors.
• Check / check / Pre-commit at .ansible/playbooks/tasks/zed.yml:57: Use failed_when and specify error conditions instead of using ignore_errors.
• Check / check / Pre-commit at .ansible/playbooks/tasks/zed.yml:23: Line too long (143 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:118: Line too long (122 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:109: Line too long (131 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:88: Line too long (139 > 120 characters)
• Check / check / Pre-commit at .ansible/variables-example.yml:174: 174:121 [line-length] line too long (125 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:118: 118:121 [line-length] line too long (122 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:109: 109:121 [line-length] line too long (131 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/eget.yml:88: 88:121 [line-length] line too long (139 > 120 characters)
• Check / check / Pre-commit at .ansible/playbooks/tasks/zed.yml:23: 23:121 [line-length] line too long (143 > 120 characters)

🛠️ Run Links

• Check