atuq: un .pyc invisible movía el hash — el hub sellaba algo que un clon limpio no reproduce
Buscando si los cambios de atuq habían llegado a la caja apareció esto: el hub y el worker calculaban `b3:e556024b` y un clon limpio `b3:5156cb8f`, con los 52 ficheros versionados de `recipes/atuq/` byte a byte IGUALES en las tres máquinas y la receta con el mismo md5. La diferencia era un fichero de más: `tools/__pycache__/rebrand.cpython-314.pyc`, bytecode que dejó alguien al correr `rebrand.py` dentro del repo. Comprobado en los dos sentidos — metiendo y sacando ese .pyc en un clon limpio, el hash salta de `5156cb8f` a `e556024b` y vuelve. Lo traicionero es que `__pycache__/` está en `.gitignore`: el árbol se ve limpio en `git status` mientras el hash ya es otro. Y el artefacto sellado en el store era el de `e556024b` — o sea uno que un clon limpio no puede reproducir jamás. Es la regla 3 al revés: no un vacío que pasa por lleno, sino basura invisible que pasa por fuente. `ArtifactHash::of_tree` no sabe de `.gitignore`, y son dos cosas legítimamente distintas; pero hoy divergen por descuido y no por decisión. Queda escrito en la receta, con la comprobación barata al lado, para las cuatro que usan `source.dir`. El `.pyc` se barrió del hub y del worker: las tres máquinas ya convergen en `5156cb8f`.
This commit is contained in:
@@ -15,6 +15,27 @@
|
||||
# vive en `recipes/atuq/` y se hashea por CONTENIDO con `ArtifactHash::of_tree`, igual que ya se
|
||||
# hacía con los `patches`. No hay commit que pinear y no hay fetch: editar un CSS mueve el hash.
|
||||
#
|
||||
# ⚠ **Y MUEVE EL HASH CUALQUIER FICHERO DEL ÁRBOL, INCLUIDOS LOS QUE `git` NO VE.** Medido el
|
||||
# 2026-09-18: el hub y el worker calculaban `b3:e556024b` para esta receta y un clon limpio
|
||||
# `b3:5156cb8f`, con los 52 ficheros versionados BYTE A BYTE IGUALES en las tres máquinas. La
|
||||
# diferencia era **un solo fichero de más**: `tools/__pycache__/rebrand.cpython-314.pyc`, bytecode
|
||||
# que dejó alguien al correr `rebrand.py` dentro del repo. Comprobado en los dos sentidos —metiendo
|
||||
# y sacando ese `.pyc` el hash salta de uno a otro—.
|
||||
#
|
||||
# Lo que lo hace traicionero es que `__pycache__/` **está en `.gitignore`**: git no lo muestra, así
|
||||
# que el árbol se ve limpio en `git status` mientras el hash ya es otro. Y el artefacto que estaba
|
||||
# sellado en el store era el de `e556024b`, o sea **uno que un clon limpio no puede reproducir
|
||||
# jamás**. Es la regla 3 de CLAUDE.md invertida: no un vacío que pasa por lleno, sino basura
|
||||
# invisible que pasa por fuente.
|
||||
#
|
||||
# `ArtifactHash::of_tree` no sabe nada de `.gitignore` — y son dos cosas distintas a propósito: lo
|
||||
# que no se versiona y lo que no entra al hash no tienen por qué coincidir. Pero hoy no coinciden
|
||||
# **por descuido**, no por decisión. Hasta que eso se decida (ver el ADR que toque), las cuatro
|
||||
# recetas con `source.dir` —`atuq`, `firmware-tigerlake`, `os-release`, `wasi-sdk`— se hashean con
|
||||
# lo que haya en el directorio, y conviene comprobarlo antes de creerle a un sello:
|
||||
#
|
||||
# find recipes/atuq -type f | wc -l # 52 · si da más, algo se coló
|
||||
#
|
||||
# ══ v0.2: EL BRANDING VIVE DENTRO DEL ZIP ══════════════════════════════════════════════════════
|
||||
# La v0.1 dejó el branding fuera porque había que mirar el árbol real antes de adivinar. Ya se miró,
|
||||
# y lo que se encontró decide la forma de esta versión:
|
||||
|
||||
Reference in New Issue
Block a user