Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#270 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Santiagocetran ci sta già lavorando.

Dal 21/10/2026.

  • #296 di @Santiagocetran — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
Python
Stelle
4
Fork
7
Merge medio
3g 58m
PR unite (30g)
39

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InfiniteZeroFoundation/DevNet

Tutte le issue di InfiniteZeroFoundation/DevNet

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.