一键导入
inference-snap-build-and-test
Build, install, and runtime-verify an inference snap including engine selection and prompt/API checks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Build, install, and runtime-verify an inference snap including engine selection and prompt/API checks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create GitHub Actions workflow files for inference snap repositories based on canonical/gemma4-snap patterns.
Run the full inference-snap workflow as a sequential chain of subagents — structure → github workflows → static checks → build & test — passing each stage's report as input to the next.
Perform static quality checks for an inference snap (snapcraft.yaml consistency, component completeness, model signature verification).
Create and adapt the inference snap structure from reference examples (packaging, engines, hooks, scripts, components).
| name | inference-snap-build-and-test |
| description | Build, install, and runtime-verify an inference snap including engine selection and prompt/API checks. |
| trigger | Keywords like "build check", "pack snap", "install and test", "prompt test", "runtime verification" |
| scope | user |
Execute end-to-end verification that the snap builds, installs, starts, and serves prompts correctly.
snapcraft pack --destructive-mode builds directly on the host, so verify these
first and stop-and-report anything missing rather than silently degrading:
OS: Ubuntu matching the snap base (e.g. core24 ⇒ noble 24.04).
Tools: snapcraft, snapd active, make, cmake, build-essential,
git, plus smoke-test deps curl, jq, ss (iproute2). Install any missing.
Root: --destructive-mode installs build-packages, so run it under sudo.
Disk: compute the summed size of the model + all shard/runtime components
and require that much free space on the filesystem backing
/var/lib/snapd/snaps (where snap install copies artifacts), not just the
build dir. A large model can exceed a small container root FS; if so, stop and
report that the root FS must be resized (or relocate snapd storage only with
explicit approval).
Approved snapd-storage relocation (workshop containers). When the
root FS backing /var/lib/snapd/snaps is too small but a large volume is
mounted (typically /project), relocate snapd's snap storage there via a
bind-mount before building. This is the established workaround and keeps
snap install off the small root FS:
sudo mkdir -p /project/.snapd-relocate/snaps
sudo cp -a /var/lib/snapd/snaps/. /project/.snapd-relocate/snaps/ # preserve existing snaps
sudo mount --bind /project/.snapd-relocate/snaps /var/lib/snapd/snaps
sudo systemctl restart snapd # re-mount snaps from new backing
df -h /var/lib/snapd/snaps # confirm large space now visible
snapcraft's own parts/, stage/, prime/ already live in the project dir
(on /project), so only snapd's storage needs relocating. Add
.snapd-relocate/ to .gitignore. Do this only with the space actually
available on the large volume; never modify container configuration.
GPU: detect /dev/nvidia* / nvidia-smi / /dev/dri. A GPU engine can
only be smoke-tested if the matching hardware is present; otherwise it will
report compatible: false and is skipped (not a failure).
The model artifacts are not committed. Before snapcraft pack, run the repo's
model preparation (typically ./download-models.sh, which may wrap
make download-models && make split-model) so the component payloads exist on
disk. For sharded models, confirm every shard landed in its component directory
with the exact filename the model.yaml layout expects.
smoke-test.sh script to verify the snap.<snap-name> list-engines --format json. Check the key compatible in the output for each engine.smoke-test.sh.