Skip to content

v0.8.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 Sep 04:04
v0.8.2
0f20f8e

修复

  • gitea.pageSize 设成 100 / 500 完全没效果。用户报告「输入 500 或者 100 都无效」。

    根因有两层，缺一不可：

    1. Gitea 服务端对单次请求的条数有硬上限。该值由服务端配置决定，并可通过
      GET /api/v1/settings/api 读到：本实例返回 max_response_items: 50。
      超出部分被静默丢弃、不报错 —— 实测 limit=51/100/200/500 一律只回 50 条。
    2. 本扩展只请求了一页。因此 pageSize 实际语义是「每页条数」而非「展示条数」，
      超过 50 的部分永远拿不到。而默认值恰好是 50，所以改成 100 或 500 后结果完全一样，
      表现为「怎么改都没反应」。

    修复：新增 GiteaClient.requestPaged()，按页收集直到凑够目标条数或没有下一页。
    所有接受 page / limit 的列表操作改走它（仓库 / Issue / PR / 通知 / 提交 / 分支 / Actions），
    因此视图与 AI 工具同时受益 —— 此前 AI 工具声明 limit 上限 100~200，
    实际同样被截断到 50。

    实测（同一实例）：limit 10→10、50→50、51→51、100→100（修复前均为 50）；
    请求 200 时因数据总量只有 105 条而返回 105 条，符合预期；小值（5）行为不变、不会多发请求。

新增

  • 列表底部新增「加载更多」，彻底移除条数硬上限。

    上一条修好了「100 拿得到」，但只要还有上限，就会有下一个上限 —— 设 200 之后想要 500 呢？
    所以不该靠不断调大数字，而是改成增量加载：

    • 列表底部若还有更多，出现一个「已显示 N 条，点击加载更多…」的条目
    • 点击后按 gitea.pageSize 追加下一批，没有上限
    • 首次展示的条数仍由 gitea.pageSize 决定（即它的语义是「初始条数」）

    已接入全部列表：仓库、分支、打开的 Issue / PR、Actions 运行记录，
    以及「我的 Issue / 我的 Pull Request / 通知」三个视图的各分组。

    实现上给 BaseTreeProvider 加了 capOf / raiseCap 记录每个列表已加载的条数，
    并由 gitea.loadMore 命令提升上限后刷新。节点的 listKey 带仓库坐标，
    因此不同仓库的同名分组互不干扰。

变更

  • gitea.pageSize 的说明改为「列表类视图初始展示多少条」，并在 schema 里补上
    minimum: 1 / maximum: 200。之前 schema 没有任何范围约束、描述只写「分页大小」，
    用户无从知道有效的取值范围与服务端限制；现在也无需靠调大它来「看全」了。

新增（仓库视图）

  • 按组织分组：仓库按 owner 归入 组织名（数量） 分组，其余按仓库数降序。

  • 聚焦当前仓库：含当前工作区仓库的那一组置顶 + 默认展开，该仓库在组内排第一
    并标注 ★ 当前。选这个做法而不是「额外放一个置顶条目」是为了避免同一仓库在树里出现两次。

  • 仓库铭牌（右侧灰色文本）：语言、分支数、开放 Issue / PR 数、Actions 关闭、已归档。
    计数为 0 的不显示 —— 实测本实例绝大多数仓库的开放 Issue / PR 都是 0，全显示只是噪音。

    只使用列表接口已返回的字段，不产生任何额外请求。因此 Actions 关闭 表达的是
    功能开关，不是「仓库里没有 workflow 文件」—— 后者需要逐个仓库调
    /actions/workflows，上百个仓库就是上百次请求，不能放在列表渲染路径上。

  • 搜索仓库（视图标题栏）：走服务端 /repos/search，因此覆盖全部仓库，
    不受 pageSize / 「加载更多」限制。搜索时结果平铺不分组（结果是跨组织的，
    分组反而妨碍扫读），列表首行显示过滤条件且可点击清除，标题栏的清除按钮仅在有过滤时出现
    （用 setContext 驱动 when）。

    实测记录一处容易踩的：服务端不按纯 owner 名搜索 —— 搜 devops 得 0 个，
    但搜 devops/cdt-ams 或 cdt-ams 各得 1 个。提示文案与空结果说明都按此写明了。

  • 新增 src/vscode/views/repoBadge.ts：刻意不依赖 vscode 模块（与 icons.ts 同一约定），
    这样铭牌逻辑能用真实数据离线渲染预览，而不是只能在扩展宿主里跑。

工程

  • 三个发布通道改为并行 job，不再是同一个 job 里连续的三步。
    原来串行本身不是大问题，真正的毛病是任一步失败会让后面的步骤被整体跳过 ——
    例如 Open VSX 出错，会导致 Marketplace 压根不去尝试发布。

    现在拆成四个 job：resolve（解析版本 + 判断该版本是否已发）、三个 publish-*
    （Open VSX / VS Code Marketplace / GitHub Packages，并行执行、独立成败）、
    以及 release（建 tag 与 Release）。「市场发布必须先于创建 Release」这条不变，
    由 needs 保证 —— 否则重跑时该版本会被判定为「已发」而永远上不了架。

  • Release 说明改从 CHANGELOG 提取（新增 scripts/release-notes.mjs）。
    原先是 gh release create --generate-notes，那生成的是按 commit / PR 自动罗列的
    摘要，与 CHANGELOG 里那份有分类、有原因、有实测数据的说明完全是两回事 ——
    结果是 Release 页面看不到真正的变更说明。

    现在三者同源：扩展市场的 Changelog 标签页 / .vsix 里的 CHANGELOG / Release 说明。
    自动摘要原本附带的版本对比链接由脚本补回。

  • 新增 npm run check:changelog，防止未填写的 CHANGELOG 区块再次发给用户。
    scripts/bump-version.mjs 升版本时会在 CHANGELOG 顶部插入一个「待补充」区块，
    而它不会自己消失 —— 0.8.1 就是这么把占位文本发到了市场（该条目本次已补上）。
    CHANGELOG 会进 .vsix、也会显示在扩展市场的 Changelog 标签页里，
    所以这不是内部问题，而是用户看得见的内容。

    校验两件事：一是没有未填占位（待补充 / 待填写 / TODO: …），
    二是最新版本标题与 package.json 的 version 一致。
    已接入 npm run ci，并且是 CI verify job 的一步 —— 依赖链是
    release → publish-* → package → verify，因此能真正挡住发布，而不只是发个警告。

完整变更对比：v0.8.1...v0.8.2

Assets 5
Loading