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

Ouverte
  • Quelque chose ne va pas ?
#527 12 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
18/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, javascript, linux, macos, node.js, playwright, rust
Domaine
devops, release, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
6
Forks
2
Merge moyen
1 j 3 h
PR mergées (30 j)
42

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de elastos/elastos-runtime

Toutes les issues de elastos/elastos-runtime

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.