Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

ci: verification stages beyond PR checks — post-merge, shared dev environment, develop→main release gate (Discussion 208 A4)

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

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

@Santiagocetran đang làm issue này rồi.

Từ ngày 21/10/2026.

  • #296 của @Santiagocetran — đang mở

Đánh giá

Issue này chưa được đánh giá.

Mô tả

enhancement Umbrella

Summary

Peer review on this repo now depends on CI for evidence. Under Developer/MAINTAINING.md (A2), a green CI OK against an up-to-date develop counts as verification for anything CI covers. Reviewers reproduce locally only what CI doesn't cover. So every gap in CI is work a reviewer has to do by hand.

In his reply on Discussion 208, @Santiagocetran proposed three verification stages beyond the PR checks. We agreed to track them here (amendment A4, step S6) so the discussion could stay about the review process.

This is an umbrella issue. Each stage below gets its own PR or sub-issue once its design is agreed in this thread.

Where we are

  • PR checks: ci.yml runs Solidity, Python (-m "not integration") and Docs on PRs and pushes to develop. CI OK is required on develop by ruleset.
  • Integration harness: isolated Anvil + Kubo + Docker runs (#213, merged).
  • Full-GI CI job: #242 (open, @sharmis-tp). It doesn't block merges (continue-on-error), has a path filter, and is tracked by #228. It can't run a complete GI until task_061026_21 lands.
  • Diagnostics from integration runs: #241 (draft, @Santiagocetran).
  • main: ci.yml doesn't trigger on main at all, so the main ruleset can't require CI OK yet.

Stages

1. Post-merge checks on develop

Check the code that actually landed on develop, not just the PR's merge preview, without re-running every expensive suite on every push.

  • Decide what runs on push to develop, as opposed to only on PRs. For example: the full-GI job on every push touching its paths, and a nightly or scheduled full run.
  • Decide who gets alerted, and how. This should line up with the merger's CI ownership in No. 4.6 and the Discussion 170 log.
  • Promote the full-GI job to a required check. A4 sets the bar: a week of green full-GI runs on develop. When promoted, it joins ci-ok's needs, with skipped accepted (the design in #242 already allows for this).
2. Shared develop/testnet environment

A long-lived network where the team can run real GI workflows together, debug, and see how each other's changes interact before release.

  • Pick the network and where it runs, for example a persistent Anvil/devnet host or a separate testnet deployment. Include who runs it and what it costs.
  • Decide how it tracks develop: redeploy on every merge, on a schedule, or by hand. Also decide how deployment addresses get published (load_din_info() / .env.<network>).
  • Decide which roles and test wallets are shared and how keys are handled. No real funds, and no DIN-Representative keys from live networks.
  • Write runbook docs under Documentation/ once it exists.
3. Validation of develop → main releases

Check a proposed release in a controlled environment that mirrors the real workflow before it's promoted.

  • Add main to ci.yml's pull_request and push triggers, then require CI OK in the main ruleset (a small first PR).
  • Define the release gate: for example, the full-GI suite plus a scripted end-to-end run against the stage 2 environment, and a contract-size or upgrade-safety check.
  • Write a short release checklist in MAINTAINING.md or Documentation/.

Constraints

  • Live networks stay with Umer (MAINTAINING No. 6): deploys or upgrades on Sepolia or any other live network, DIN-Representative keys, and slasher authorisations. Stage 2 is a development environment, not the live DevNet.
  • One required check: ci.yml keeps no path filters at the workflow level, and CI OK stays the single required check. New jobs feed into it.
  • Pinned tools: versions stay pinned (FOUNDRY_VERSION, .github/constraints-ci.txt, checksummed downloads), and nothing is fetched unpinned at test time.

Owner

@Santiagocetran leads, @umeradl reviews and decides stage 2 hosting/cost. Related: #228, #241, #242, task_061026_21.

Ngôn ngữ chính
Python
Star
4
Fork
7
Merge trung bình
3 ngày 58 phút
Pull request đã merge (30 ngày)
39

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 InfiniteZeroFoundation/DevNet

Tất cả issue của InfiniteZeroFoundation/DevNet

Issue tương tự

Thêm issue về Python

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.