Environment & config reporting: publish-time manifest + central data store

Aperta
  • Qualcosa non va?
#30 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
anaconda, github-actions, python, shell
Ambito
build-system, ci-cd, devops

Direzione di ricerca

Inizia da publish-gh-pages/action.yml, setup-environment/action.yml, dai Dockerfiles referenziati e dal workflow test-container.yml; confronta i relativi output esistenti, i marker e l’ispezione del manifest. Leggi le convenzioni dello schema di report-data.json prima di definire il record versionato. Il lavoro è completato quando i dati concordati sull’ambiente effettivo vengono prodotti con la cadenza indicata, includono i campi elencati e vengono inviati a status-lectures o sono altrimenti disponibili per la reportistica sulla copertura e sul drift.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Per @jstac: environment data is pull (status pages/dashboard), the weekly report shows only diffs. This issue is the producer: an env record per lecture repo, fed to QuantEcon/status-lectures (JSON store + Pages dashboard).

Today

  • publish-gh-pages/action.yml:126-136 writes {name, tag, commit, timestamp, size_mb, file_count, repository} as a release asset beside the tarball and SHA256 checksum (publish-gh-pages/action.yml:144-152); no schema_version, environment, digest or cache/runner/duration fields, and nothing here repository_dispatches.
  • Opt-in and tag-only: gated on create-release-assets == 'true' (:82, default 'false' at :16); :90 exits early when GITHUB_REF_TYPE != tag.
  • Computed then discarded: setup-environment/action.yml:35-41 outputs container-mode and conda-cache-hit; :207 runs pip list 2>/dev/null || conda list into a log group.
  • No digest source: markers containers/quantecon-build/Dockerfile:100-103 and containers/quantecon/Dockerfile:99-101 carry image=, build_date=, variant= (build image only), no tag/digest, and setup-environment/action.yml:175 parses only image=. Resolve it in the workflow or bake it into the marker at build time; .github/workflows/test-container.yml:99 already docker manifest inspects :latest from a host runner, for image size only. The digest makes #129's first gap measurable: both images publish and consume mutable :latest.

Tasks

  • Cadence first: per-tag = release provenance; per-gh-pages-deploy (small JSON, no tarball) = what status-lectures needs for drift detection and the dashboard-as-migration-tracker. Schema follows.
  • Schema: versioned per-repo env record with schema_version (report-data.json conventions): stub fields plus container image + digest, container-mode, conda-cache-hit, runner, build duration.
  • Publish-push (primary): publish-gh-pages (and/or setup-environment) emits the effective-environment manifest and dispatches it to status-lectures. Effective = resolved conda list/pip freeze, container digest/tag, cache hit/miss, build duration, runner.
  • Daily backstop (secondary): scheduled scrape of _config.yml + environment.yml for unmigrated repos, plus declared-vs-effective drift detection (store/scheduling in status-lectures; collection logic shareable from here).
  • Coverage: reporting via publish-push == migrated to the centralized actions, so the dashboard doubles as a migration tracker.

Fields: python · anaconda/conda pin · jupyter-book · theme · sphinx extensions (+versions) · execute mode + timeout · only_build_toc_files · launch buttons · intersphinx targets · container vs conda + tag/digest · runner (ubuntu vs AWS GPU) · GPU? · cache strategy · build duration.

Part of QuantEcon/meta#321.

Lingua principale
Shell
Stelle
0
Fork
1
Merge medio
20h 3m
PR unite (30g)
48

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di QuantEcon/actions

Tutte le issue di QuantEcon/actions

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.