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

Offen
  • Stimmt etwas nicht?
#527 12 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
18/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, javascript, linux, macos, node.js, playwright, rust
Bereich
devops, release, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
6
Forks
2
Ø Merge
1 T. 3 Std.
Gemergte PRs (30 T.)
42

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus elastos/elastos-runtime

Alle Issues in elastos/elastos-runtime

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.