Certify Microcosm builds published side by side in their own release folders
维护者通常 1 天内回复
评估
调研方向
Start with the certification and import-time compatibility checks that use release_build_id, then trace manifest parsing and dataset artifact paths. Compare the existing cut_tag behavior with the microcosm_emitter_interface.releases format referenced in the issue. Done means string-valued release and build manifests certify files under their release folder, imports reject mismatched release or build names, and older manifests retain their current behavior.
由索引模型根据 Issue 内容生成。
描述
Problem
Microcosm is moving its dataset repositories to a new publication layout:
- each build is published once, in its own folder,
releases/<release>/<build>/, and that folder never changes afterwards; - one
releases.jsonat the repository root records which build of each release is current; - no new Hugging Face tags are created;
- each build's
release_manifest.jsonnames itsreleaseandbuildas two strings (the build is the attempt ID Microcosm already assigns, for exampleuk-frs-calibration-attempt-20261019T083323Z-6cba5d71), and no longer carriescut_tag.
The format of releases.json and the publication checks are in microcosm-emitter#24 (microcosm_emitter_interface.releases). Microcosm switches to the layout in a later change, after a one-time migration of the existing UK builds.
Certification and the import-time compatibility check currently name a data build with release_build_id, which prefers build.cut_tag (#615). They also assume build is an object. A manifest in the new layout:
- would fail to parse, because its
buildis a string; - has no tag to pin, so a certificate has to pin the build by its folder path instead;
- keeps its files inside the build folder, while today's dataset artifact paths are relative to the repository root.
Proposed change
- Parse a manifest whose
releaseandbuildare strings, and name its build bybuild, so two builds of one release never match. - Certify such a build from its own folder: the manifest URI must be
releases/<release>/<build>/release_manifest.json, and the build's files are pinned atreleases/<release>/<build>/<file>at the revision the manifest was certified at. - At import, refuse a remote manifest that names a different release or build than the folder it was read from.
- Keep manifests published before the layout (with
cut_tag) behaving exactly as they do now.
Relates to #553 and #615.
- 主要语言
- Python
- 星标
- 8
- 派生
- 10
- 平均合并
- 1 天 2 小时
- 30 天内合并 PR
- 50
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
PolicyEngine/policyengine.py 的其他 Issue
-
Raise the simulation cache memory warning to 16 GiB可能已有人在做 @anth-volk 于 22 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
PolicyEngine/policyengine.py#549 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
PolicyEngine/policyengine.py#473 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
PolicyEngine/policyengine.py#436 · 1 条评论 ·
维护者通常 1 天内回复
-
Certify populace-uk as the UK certified default可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
PolicyEngine/policyengine.py#408 ·
维护者通常 1 天内回复
-
Stop trusting the compromised eMudhra CA certificates可能已有人在做 @anth-volk 于 1 天前认领。 未关闭
难度 5/5 一周以上 新手友好度 15/100
PolicyEngine/policyengine.py#698 ·
维护者通常 1 天内回复
查看 PolicyEngine/policyengine.py 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 77/100
khuisman/mcp-gee-sweet#1166 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 70/100
lugassawan/swe-workbench#823 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
gramaziokohler/compas_timber#870 ·
-
security-scan-failure
难度 2/5 1-3 小时 新手友好度 78/100
semantica-agi/semantica#2089 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
autowarefoundation/autoware_carla_scenario#500 ·
维护者通常 1 天内回复