@dptech-corp/bohr-cli 2.6.38-preview.777 → 2.6.39
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -0
- package/package.json +7 -7
package/CHANGELOG.md
CHANGED
|
@@ -15,6 +15,24 @@
|
|
|
15
15
|
|
|
16
16
|
## [Unreleased]
|
|
17
17
|
|
|
18
|
+
## [2.6.39] - 2026-08-21
|
|
19
|
+
|
|
20
|
+
### Added
|
|
21
|
+
|
|
22
|
+
- **`bohr job_group terminate` / `delete` 也接受 `bohrJobGroupId`**：一个任务组有两个标识（`job_group list` 同时透出 `id` 与 `bid`），此前这两条命令只收 `id`，而 `job submit -g` 与 `job submit` 返回的 `bohrJobGroupId` 给的是 `bid`——同一个组做不同的事要拿不同的号，拿错就报 `record not found`，看起来像组不存在。现在传 `bid` 会被自动换成 `id` 再发出；传 `id` 的行为与调用次数均不变。
|
|
23
|
+
|
|
24
|
+
- **上一条换不出来时会说明该用哪个 ID**：换算依赖任务组下的作业已被索引，而刚 `job submit` 完的组要等几秒才可查，恰好是最常见的「提交完就停整组」场景。此时报错的 code、HTTP 状态与文案一律保持上游原样，只补一条 hint 说明该改用 submit 响应里的 `jobGroupId`——那个值调用方手上本来就有。
|
|
25
|
+
|
|
26
|
+
- **`bohr job submit` 输出可直接回传的任务组 ID**：新增 `bohrJobGroupId`（`-o json`）/ `BohrJobGroupId`（human），即 `-g` 真正接受的那个值。此前返回体里的 `jobGroupId` 来自平台 ID 空间，拿它回传 `-g` 必然报 `JobGroup(<id>) not find`，而可用的那个只能另外从 `bohr job_group list` 的 `bid` 或 `bohr job_group create` 的 `groupId` 取；现在提交完即可直接用返回值把后续作业提进同一个组。原有字段一律保留、取值不变，`-g` 的帮助文案同时写明了该收哪个值。
|
|
27
|
+
|
|
28
|
+
### Fixed
|
|
29
|
+
|
|
30
|
+
- **多个 ID 时不再只处理第一个**：`job_group terminate`、`job_group delete`、`image delete`、`job delete` 这四条命令在 `-o json` 等机读输出下，处理完第一个 ID 就返回了——`bohr job_group terminate A B -o json` 只停 A，B 从未被请求，且退出码为 0。human 输出下同理，第一个失败的 ID 会中断其后全部 ID；`job delete` 尤其严重：首个 ID 解析失败时，后面本可删除的作业一个都不会被删。现在四条命令都会走完全部 ID，失败的一个不影响其后的，退出码如实反映任何一次失败。机读输出沿用仓库既有的批量约定（`envelope.Batch`，与 `dataset delete`、`sandbox delete`、`job stop` 一致）：单个 ID 的输出形态完全不变，多个 ID 汇总为一个 batch envelope，每个 ID 一条结果。
|
|
31
|
+
|
|
32
|
+
- **`bohr job submit` 的响应异常不再把两种失败写成同一句话**：建组、建任务、提交三个阶段此前对任何异常响应都只报 `invalid <阶段> response`，并丢掉底层的解码错误——「响应结构变了」和「结构对但字段缺失/为 0」这两种归属完全不同的失败，读到的文案一模一样。现在解码失败会带上原始错误，字段异常会点名是哪个字段、实得什么值（如 `job creation response carries no upload token`）。
|
|
33
|
+
|
|
34
|
+
## [2.6.38] - 2026-08-19
|
|
35
|
+
|
|
18
36
|
### Fixed
|
|
19
37
|
|
|
20
38
|
- **`bohr trisol` 在登录态过期后自动续期，不再把过期 token 注入子进程**：此前 trisol 启动时把磁盘登录态里的 access token 原样注入 `TRISOL_TOKEN`，token 一过期 trisol 全部命令收到无归因的裸 `401`，而 refresh token 明明有效（wenyon 有续期路径、trisol 没有）。现在注入前统一走「过期即用 refresh token 换新」的判定，wenyon 与 trisol 同口径。续期失败分两级：vouch 服务端明确拒绝（refresh token 已失效）时拒绝启动并提示 `bohr auth login`；瞬时失败（网络错、5xx）保留登录态、告警后照常启动，一次网络抖动不再毁掉有效会话。wenyon 自有 `~/.vouch/state.json` 仍有效或完全没有登录态时照常启动。
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@dptech-corp/bohr-cli",
|
|
3
|
-
"version": "2.6.
|
|
3
|
+
"version": "2.6.39",
|
|
4
4
|
"description": "CLI tool for Bohrium scientific computing platform",
|
|
5
5
|
"bin": {
|
|
6
6
|
"bohr": "run.js"
|
|
@@ -32,11 +32,11 @@
|
|
|
32
32
|
"CHANGELOG.md"
|
|
33
33
|
],
|
|
34
34
|
"optionalDependencies": {
|
|
35
|
-
"@dptech-corp/bohr-cli-darwin-
|
|
36
|
-
"@dptech-corp/bohr-cli-darwin-
|
|
37
|
-
"@dptech-corp/bohr-cli-linux-amd64": "2.6.
|
|
38
|
-
"@dptech-corp/bohr-cli-linux-arm64": "2.6.
|
|
39
|
-
"@dptech-corp/bohr-cli-windows-amd64": "2.6.
|
|
40
|
-
"@dptech-corp/bohr-cli-windows-arm64": "2.6.
|
|
35
|
+
"@dptech-corp/bohr-cli-darwin-arm64": "2.6.39",
|
|
36
|
+
"@dptech-corp/bohr-cli-darwin-amd64": "2.6.39",
|
|
37
|
+
"@dptech-corp/bohr-cli-linux-amd64": "2.6.39",
|
|
38
|
+
"@dptech-corp/bohr-cli-linux-arm64": "2.6.39",
|
|
39
|
+
"@dptech-corp/bohr-cli-windows-amd64": "2.6.39",
|
|
40
|
+
"@dptech-corp/bohr-cli-windows-arm64": "2.6.39"
|
|
41
41
|
}
|
|
42
42
|
}
|