registrystack / registrystack/registry-stack
Harden local docs sync against dirty sibling checkouts
- Lingua principale
- Rust
- Stelle
- 2
- Fork
- 0
- Merge medio
- 2h 55m
- PR unite (30g)
- 130
Descrizione
Migrated from: https://github.com/jeremi/registry-docs/issues/71
Original author: @jeremi
Source repository: `jeremi/registry-docs`
Source issue: `#71`
Source labels: enhancement, post-1.0
Source milestone/release intent: _none_
Target area/path: `docs/site`
## Issue
Audit candidate: CAND-ARTIFACTS-01, downgraded to local tooling hygiene.
Background:
GitHub Pages builds use clean runners and pinned refs, so this is not currently a public docs publication risk. Local developer builds can still prefer an existing sibling checkout without checking cleanliness or HEAD, which can confuse local review or generated archives.
Acceptance criteria:
- Local docs sync warns, rejects, or ignores sibling checkouts that are dirty or not at the pinned ref.
- GitHub CI behavior remains pinned-clean and does not depend on local sibling paths.
- Tests or script checks cover dirty and wrong-ref sibling checkout cases.
Non-goals:
- Changing public GitHub Pages deployment if it already builds from clean pinned refs.
## Migration Metadata
- Migrated to the public monorepo on 2026-06-25.
- Source title, body, labels, milestone/release intent, and pre-migration discussion were preserved where available.
- Code-grounded audit note: Docs sync still prefers sibling checkouts and lacks dirty/wrong-ref gates.
- Private/internal references, secrets, and obvious deployment-only details were redacted instead of copied forward.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia in docs/site e individua il punto di ingresso della sincronizzazione locale della documentazione; esamina come vengono selezionati i checkout adiacenti e come vengono rappresentate le refs fissate. Aggiungi controlli o avvisi per i checkout adiacenti con modifiche non confermate e con la ref errata, preservando il comportamento pulito di CI con refs fissate, quindi copri entrambi i casi con test o controlli nello script.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- git, github-actions
- Ambito
- documentation, tooling
- Tipo di issue
- Funzionalità
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 55/100