Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#270 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

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

@Santiagocetran y travaille déjà.

Depuis le 21/10/2026.

  • #296 par @Santiagocetran — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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.

Langage dominant
Python
Étoiles
4
Forks
7
Merge moyen
3 j 5 h
PR mergées (30 j)
34

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

Toutes les issues de InfiniteZeroFoundation/DevNet

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

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