Pipeline: catch release-only and long-session failures before signing

Abierto
  • ¿Algo no está bien?
#527 12 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, javascript, linux, macos, node.js, playwright, rust
Área
devops, release, testing

Línea de trabajo

Start with the gate and CI command lists (test-source-gate.sh, just verify, and the product-ui-browser job), then inspect the named smoke scripts and the Apple silicon test path. The issue calls out specific failing assertions and coverage gaps, but spans release validation, installed Mac journeys, long Browser sessions, and platform-specific gate planning. Done means each retained check is wired into a gate or CI, demonstrated failing before and passing after on the relevant change, with the named smoke assertions and timing thresholds validated.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

From the 25 Oct to 4 Nov review of the delivery pipeline (lesson ledger, CI history, push queue log, rented machine history): the checks catch real bugs, but several kinds of failure are found only at release time or by users, after hours of work have been built on top.

  • Release-only paths cost about 6.5 hours (ledger: the release's own CHANGELOG section is read only at prepare; universal archives differ between macOS and Linux and only prepare compares them).
  • A Browser crash at about 485 s escaped because no qualification keeps a session open that long (ledger 876).
  • #515 (Mac update with the local AI engine fails on the sealed engine tree) was found after 2.0.0 shipped: no installed update journey has the engine present.
  • Smoke scripts that no gate runs rot: browser-source-home-config-smoke.sh already fails on develop unnoticed; the Browser settlement smoke is run by hand only.
  • A Rust change passes the full Linux remote check and then runs the same full gate again on the Mac at push.

Done means

  • Qualification (before Anders signs) runs the release preparation validator against the assembled artifacts, so a missing CHANGELOG section or a platform-dependent archive fails before signing, not after the seed upgrade.
  • The installed Mac update journey runs with the local AI engine installed and fails on today's #515 behaviour.
  • Browser qualification keeps one session open at least 10 minutes with input, then Close and reopen, on the Mac.
  • Every smoke script is either run by the gate or CI, or deleted.
  • When a full Linux remote-check PASS receipt exists for exactly the pushed tree, the Mac pre-push gate runs only what differs on macOS (crates with macOS cfg code) plus the cheap steps; any tree change runs the full gate as today.
  • Each item has a check that failed before its change and passes after.

Related: #515, #90.

Source audit — 6 November 2026

Candidate: develop f50e448b3e98c813106f0b17b2bf5d7fee8f5f18, tree 8fa9e56488d5a9b7c9968689b2b7a3da790ce9ed. Root checked a source export against all 1,972 Git blob identities and executable modes.

Two checks still fail outside test-source-gate.sh, just verify and CI's command lists:

  • node scripts/check-system-esp-projections.mjs stops at line 36 because it expects binding.executable !== true in System's removed Apps & Services inventory. The projection-helper cases after that assertion do not execute. Keep the adapter behaviour tests, and move any needed executable-binding refusal check to the current Runtime consumer.
  • bash scripts/browser-source-home-config-smoke.sh stops at line 304 because it requires a legacy Linux hibernation variable that the native transport configuration omits. Update its native Linux assertions for the current generator, retaining the Runtime networking, readiness, session and profile boundaries. Review the remaining legacy launcher/pool assertions in the same fixture before accepting it.

docs/HOME_MOBILE.md:172 still claims just verify runs the deleted home-entropy-check.mjs. Point the documentation to the actual checks and retain each accepted phone contract in a runnable check. The current AGENTS.md already names the replacement product-data checks correctly.

Root independently passed 485 Node tests with zero skips, the Home/UI/data/contract checks listed in #535, and both required Rust format checks. The separate CI release-policy suite stopped before running tests because the plain source export has no Git index; this is an audit-environment limitation. Root left builds, full pre-push, installed journeys and target tests with Main.

Next owner: Main. Repair these checks within this issue, show fail-before/pass-after, and put each retained smoke in an existing gate or delete it under the accepted criterion. This audit adds no second active lane and leaves the installed, long-session and human acceptance gates open.

Two confirmed coverage gaps on 2.0.1-rc.1

On 30b166b05e1e4e29e97597aad25a688a19380ad1, Root checked the source behind the completed coverage audit. The private stdin preflight test requires Apple silicon, the workspace CI test runs on Ubuntu, and the local pre-push test planner selects only libraries and binaries. The audit reports a direct Mac pass for the preflight test. That result does not establish gate coverage.

Main owns the gate repair. Add the named preflight test to the existing Apple silicon test path and record a completed result for that test on the change's commit. The Library performance smoke has no gate caller. The existing product-ui-browser job already installs the Playwright and Chromium it needs. Check the smoke there and retain its large-folder rendering, cache reuse and upload assertions. Validate the timing thresholds on that runner before making them blocking. Keep the reported missing-Playwright attempt and the earlier CI failures in the record.

Lenguaje dominante
Rust
Estrellas
6
Forks
2
Merge medio
1 d 3 h
PR fusionados (30 d)
42

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de elastos/elastos-runtime

Todos los issues de elastos/elastos-runtime

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.