47 lines
2.6 KiB
Markdown
47 lines
2.6 KiB
Markdown
# 建仓、打 Tag、选用引擎（人工）
|
||
|
||
本仓没有自动提交命令。CI 构建镜像、在凭据齐全时推送，并把镜像注册到 `image-verify`。注册只是让适配页能看到这个引擎，不等于代领或代提交适配任务。
|
||
|
||
积分：待平台核实。
|
||
|
||
## 1. 在 Gitea 建仓
|
||
|
||
1. 在模盒的 Gitea 上新建仓库，名称建议 `modelhub-engine-bi150-compat`。
|
||
2. 把本目录推上去。不要提交 `.env`、密钥或 Token。
|
||
3. 确认默认分支上有 `Dockerfile`、`.gitea/workflows/build.yml` 和 `.gitea/workflows/task_info.env`。
|
||
|
||
## 2. 打 Tag
|
||
|
||
CI 在 `v*` 标签上触发，例如 `v0.1.0`。
|
||
|
||
```bash
|
||
git tag v0.1.0
|
||
git push origin v0.1.0
|
||
```
|
||
|
||
标签名会成为镜像标签。
|
||
|
||
## 3. 看 CI
|
||
|
||
流水线顺序：`Clone → Load task info → Validate Image Verify Metadata → Build image → Push → Notify Image Verify`。
|
||
|
||
1. 打开该 Tag 的 Actions / 流水线。
|
||
2. `Load task info` 应打印 `FRAMEWORK=vllm_bi150_r2r4` 和 `GPU_TYPE=Iluvatar_bi-150`。
|
||
3. `Validate Image Verify Metadata` 在构建前 GET `adminApi/image-verify/validate`，校验 `gpuType` 与 `taskType`。缺 `FIXED_TOKEN` 这步直接失败。
|
||
4. `Build image` 执行 `docker build`。基线镜像拉取失败时，日志会停在构建步骤；无卡不能代替真机验证。
|
||
5. `Push` 需要 `DOCKER_REGISTRY`、`DOCKER_USERNAME`、`DOCKER_PASSWORD`。缺任意一项就打印 build-only 并成功结束，不推送。
|
||
6. `Notify Image Verify` 只在推送成功后 POST `adminApi/image-verify`，把 `framework`、`gpuType`、`imageUrl`、`taskType`、`createBy`、`repoUrl`、`tag` 注册上去。build-only 时跳过，因为没有真实 `imageUrl`。
|
||
7. `FIXED_TOKEN` 与 Harbor 密码都由 Runner 注入，不写进仓库，也不在日志里打印。打新 Tag 前先确认旧 Harbor 密码已轮换。
|
||
|
||
旧 Tag 不会自动补注册。`v0.1.0` 没有 Notify 步骤，必须打新 Tag 重跑。
|
||
|
||
## 4. 在模盒选用引擎
|
||
|
||
1. 用浏览器登录模盒。
|
||
2. 在适配任务的引擎下拉里确认能看到 `vllm_bi150_r2r4`，且开发者 / `createBy` 是 `VC_noSugar`（或页面等价展示）。如果看到的是别人的名字，说明 FRAMEWORK 又撞名了。
|
||
3. 等镜像审核通过。审核状态由人在页面上确认。
|
||
4. 在适配任务里选用该引擎。本仓不代为创建或提交任务。可用 `Qwen/Qwen2.5-0.5B-Instruct`（`Qwen2ForCausalLM`，在 R4 白名单内）只做下拉可见性抽检。
|
||
5. 把审核通过时间、镜像 tag、`imageUrl`、以及首次被选用的适配任务 ID 写入 `docs/evidence.md`。积分栏保持「待平台核实」。
|
||
|
||
字段以登录后的控制台为准。
|