Skip to content

CI/Nightly End-to-End Validation of FOC as a whole #8

@BigLep

Description

@BigLep

Done Criteria

  • CI pipeline (or scheduled workflow) exists that:
  • Runs on a schedule (e.g. nightly) and is visible to the team.
  • On failure:
    • CI run is clearly marked as failed.
    • Logs are preserved for debugging.
    • It's clear what branches/tags/commits were used so that a developer can reproduce the failure.
    • GitHub issue is created in the repo for visibiltiy for the team. (We can do something similar to what Lotus does for its periodic "very expensive tests")

Why Important

  • Detects cross-repo breakages before they reach calibnet/mainnet hopefully.
  • Provides an early warning system for regressions in core flows.
  • Supports GA and post-GA stability by continuously validating the “golden paths”.

##User/Customer

  • Primary: Entire FOC engineering team.

Notes

  • Start with nightly-only; maybe we'll consider per-PR jobs later for critical components.
  • Keep logs and artifacts lightweight but sufficient for root-cause analysis.
  • This issue was clarified based on discussion in Nightly CI runs, needs clarity #17

What to run against

We want two sets of runs:

  1. Latest set of tagged releases
  2. Latest changes in "main" branches.

Specifically:

repo "master" branch latest release tag
curio pdpv0 pdp/vX
lotus master vX
filecoin-services main vX
synapse-sdk master synapse-sdk-vX

Where to run this

We'll do this in a new repo to now avoid more clutter to existing "central" repos like synapse-sdk. We'll do this in a new repo "foc-integ-tests" that houses both various integration test scenarios (where an example scenario will be created following #7 ) and the ci yaml files to periodically run these scenarios.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

🐱 Todo

Relationships

None yet

Development

No branches or pull requests

Issue actions