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

Đang mở
  • Có gì không ổn?
#527 12 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
18/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, javascript, linux, macos, node.js, playwright, rust
Lĩnh vực
devops, release, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
6
Fork
2
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
42

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của elastos/elastos-runtime

Tất cả issue của elastos/elastos-runtime

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.