[Feature] Allow choosing the CUA image flavour (container or VM) in the CUA Image setting

オープン
  • 何か問題がありますか？
#10,844 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
1/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
docker, python
領域
backend

調査の方向性

Pull request #10835 is already open for this feature. Review its changes to see how it parses the CUA Image setting, selects the requested flavour, and handles unsupported flavours; check that registry image tags remain unchanged and that no schema or API client changes are needed.

索引モデルが issue の本文から書いたものです。

説明

Feature Description / 功能描述

English

The CUA Image setting currently accepts only a factory name such as linux, macos, windows or android, and the CUA SDK decides how to realise it. For a local Linux sandbox that means a QEMU virtual machine: the host needs QEMU installed, and the first start downloads a portable QEMU build.

Running the same Linux image in a Docker container is much lighter and is what most local deployments already have, but there is no way to ask for it.

This feature adds an optional :container or :vm suffix to the setting, for example:

CUA Image = linux:container

Only the known flavours are split off, so the tag of a registry reference such as ghcr.io/trycua/xfce:latest is not mistaken for a flavour and the reference is looked up unchanged. When the selected SDK factory does not support the requested flavour, the suffix is ignored with a warning instead of failing the boot. No new configuration key is introduced, so the dashboard schema and the API client stay unchanged.

A PR implementing this is open for review: #10835.

中文

CUA Image 目前只能填工厂名（如 linux、macos、windows、android），实际形态由 CUA SDK 决定。本地 Linux 沙盒会走 QEMU 虚拟机：宿主机需要安装 QEMU，首次启动还要下载 QEMU portable 资源。

而用 Docker 容器运行同一个 Linux 镜像要轻量得多，多数本地部署本来就有 Docker，却没有办法指定。

本功能为该配置项增加可选的 :container / :vm 后缀，例如：

CUA Image = linux:container

只识别已知形态，因此 ghcr.io/trycua/xfce:latest 这类镜像引用的 tag 不会被误判为形态，镜像名会原样参与查找。当所选 SDK 工厂不支持该形态时，仅记录警告并忽略，不会导致启动失败。本功能不新增配置键，dashboard schema 与 API client 均无需变更。

对应 PR 已开启，欢迎评审：#10835。

Use Case / 使用场景

English

  • A local deployment that already runs Docker Desktop (or Docker Engine) wants to use the CUA sandbox without installing QEMU and without waiting for a large QEMU download.
  • A deployment on a host without KVM acceleration prefers a container over a virtual machine.
  • Operators want to choose the flavour explicitly per installation instead of relying on the SDK default, and want to be able to switch back by editing a single setting.

中文

  • 本机已经装了 Docker Desktop（或 Docker Engine），想在不安装 QEMU、不等待大体积 QEMU 下载的前提下使用 CUA 沙盒。
  • 宿主机没有 KVM 加速，希望用容器而不是虚拟机。
  • 希望能按安装环境显式选择形态，而不是依赖 SDK 默认值，并且改一个配置项就能切回去。
Checklist / 检查清单
  • I have searched the Issue list for related features and confirmed this feature idea has never been proposed.
    / 我已在 Issue 列表中搜索过相关功能，确认该功能想法从未被提出过。
  • The feature I am suggesting is related to AstrBot itself, not to a specific plugin.
    / 我建议的功能与 AstrBot 本体相关，而非在建议某一插件的功能。
  • I have read and agree to the project's Code of Conduct.
    / 我已阅读并同意本项目的贡献者行为准则。
  • (Optional) I am willing to submit a PR to help implement this feature.
    / (可选)我愿意提交 PR 以帮助实现该功能。

Thank you for sharing your valuable ideas with us! / 感谢您向我们提交您宝贵的想法！

主要言語
Python
スター
46.4k
フォーク
3.4k
平均マージ
1日 11時間
マージ済み PR（30日）
120

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

AstrBotDevs/AstrBot のほかの issue

AstrBotDevs/AstrBot の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。