Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#270 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@Santiagocetran がすでに取り組んでいます。

2026年10月21日 から。

  • #296 @Santiagocetran による — オープン

評価

この issue はまだ評価されていません。

説明

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.

主要言語
Python
スター
4
フォーク
7
平均マージ
3日 58分
マージ済み PR（30日）
39

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

InfiniteZeroFoundation/DevNet のほかの issue

InfiniteZeroFoundation/DevNet の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。