Certify Microcosm builds published side by side in their own release folders

Offen
  • Stimmt etwas nicht?
#682 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@anth-volk arbeitet bereits daran.

Seit 20.10.2026.

  • #683 von @anth-volk — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
python
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.json at the repository root records which build of each release is current;
  • no new Hugging Face tags are created;
  • each build's release_manifest.json names its release and build as two strings (the build is the attempt ID Microcosm already assigns, for example uk-frs-calibration-attempt-20261019T083323Z-6cba5d71), and no longer carries cut_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 build is 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 release and build are strings, and name its build by build, 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 at releases/<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.

Vorherrschende Sprache
Python
Sterne
8
Forks
10
Ø Merge
1 T. 9 Std.
Gemergte PRs (30 T.)
50

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PolicyEngine/policyengine.py

Alle Issues in PolicyEngine/policyengine.py

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.