CI-esta: faster GitHub Actions with evidence
A measured Windows optimization reduced pytest-selective's full validation gate from 249s to 185s and its dependency critical path from 242s to 177s, with every original case and coverage retained. Raw reports and a fresh unchanged control accompany the claim. The same investigation reduced Saleor's full conformance test duration from 223.8s to 205.1s with warm caches on both sides, retaining all 226 original cases and outcomes.
For slow test execution after routing is correct, see critical-path optimizations: isolated PostgreSQL worker databases and native Git on Windows, with full conformance and coverage retained.
Let proven work rest. Measure the rest.
For Bun TypeScript/React suites, use the Bun affected-test adapter. It keeps the repository's test inventory and contracts, uses Bun's native graph, and reports through the same CI-esta work-selection API as other runners.
Find the 279-second job hiding in a 295-second CI run. That is what this real report exposed. Pair measurement with pytest-selective: its matched README experiment used 92.3% less runner time, 627s → 48s, through input routing. The measured results and attribution are below; no universal or receipt-reuse saving is claimed.
CI-esta is an open-source toolkit for GitHub Actions optimization and CI observability. It measures where a workflow spends time and reuses successful validation only when matching execution evidence exists. Your application can use any language.
Repeated CI work is easy to skip incorrectly: the previous workflow was green but the relevant lane never ran, the PR base moved, a newer rerun failed, or the change list was incomplete. CI-esta makes those decisions explicit and falls back to doing the work when proof is uncertain.
Have your agent improve CI
Paste this into your coding agent in the repository you want to improve:
Read https://raw.githubusercontent.com/gigaverse-app/ci-esta/main/skills/ci-esta/SKILL.md
and use it to measure and improve this project's GitHub Actions CI. Preserve
required checks and show measured savings. Use pytest-selective for Python tests.
Install the skills or add AGENTS.md instructions. Any application language on GitHub Actions; no new MCP server or hosted service.
What is included
| Tool | What it does |
|---|---|
ci-observability |
Required-gate latency, job admission delay, all-attempt runner time, configured cost estimates, overlapping runs; JSON, Markdown and Prometheus |
resolve-lane-evidence |
Reuse a passing lane with a matching completion receipt, bounded freshness and conservative failure handling |
resolve-incremental-pr-base |
Find a proven successful ancestor for incremental scanners; fall back to the PR base |
validation-gate |
Fail on missing, failed, cancelled or unexpectedly skipped prerequisites |
collect-pr-changes |
Collect a complete PR file list bound to the observed head and base; detect truncation and races |
publish-prometheus-snapshot |
Replace a stable, repository-isolated Pushgateway group without run/SHA label growth |
All actions live in this repository. No hosted CI-esta service is required. Evidence and gate actions use JavaScript; reporting uses an isolated Python runtime. A pytest application is not required.
Start by measuring one workflow
# .github/workflows/observe-ci.yml
name: CI observability
on:
workflow_run:
workflows: [CI] # Your validation workflow's name
types: [completed]
permissions:
contents: read
actions: read
checks: read
pull-requests: read
jobs:
report:
uses: gigaverse-app/ci-esta/.github/workflows/report.yml@v0.1
with:
run-id: ${{ github.event.workflow_run.id }}
run-attempt: ${{ github.event.workflow_run.run_attempt }}
head-sha: ${{ github.event.workflow_run.head_sha }}
required-gates-json: '[{"kind":"actions_job","job_name":"Validation gate"}]'
analyze-critical-path: true
Replace the workflow and required job names with yours. Commit this observer to your default branch; it reports future completed runs without becoming a validation prerequisite. The pinned reusable workflow writes a summary and JSON/Markdown/Prometheus artifacts with read-only permissions. See the observability guide for costs and local CLI usage, then adopt evidence reuse and strict gates. Our validation workflow and observer are complete examples.
Who runs CI-esta
| Project | Runs | What it bought |
|---|---|---|
| Due | Reports and the required-check gate | The gate lets a docs-only PR skip the test matrix while required checks tests (locked) and tests (minimum) still report. With pytest-selective, a library-test change finishes main CI in 3m24s instead of 6m03s. Reports surfaced 404–431s CPU-profiling steps, now being cut in Due #72. |
| pytest-obligation | Reports | A package README change uses 57 runner-seconds instead of 1,691. The observer replaced an inline timing job, so validation no longer waits for telemetry (#98). |
| pytest-selective | Reports | Found a 279s Windows job on a 295s validation path, for 19 runner-seconds of reporting. |
The skipped-lane savings come from pytest-selective routing; CI-esta's part is the gate that keeps a skip honest and the reports that show what to cut next. CI-esta also renders pytest-selective's selection explanations, importing its models instead of keeping a copy. A reused lane is not a conformance certificate: Due and pytest-obligation keep their executed pytest-obligation evidence checks. See how the projects fit together.
Running CI-esta? Say so in your README:
[](https://github.com/gigaverse-app/ci-esta)
What measured runs show
Explicit input routing with pytest-selective reduced work in these successful GitHub Actions pairs:
| Change | Full runner-seconds | Selected runner-seconds | Reduction |
|---|---|---|---|
| pytest-selective README | 627 | 48 | 92.3% |
| Due library test, main CI | 747 | 388 | 48.1% |
| pytest-obligation MongoDB test | 1,602 | 93 | 94.2% |
| pytest-obligation package README | 1,691 | 57 | 96.6% |
These are one sequential pair per scenario on the same PR head and merge checkout, including planner overhead. Raw timestamps, run links and limitations are published with the selector. Runner-seconds sum executed-job durations; they are not billed minutes. Due's separate widget benchmark is excluded here. These savings come from selection and consumer input declarations, not CI-esta receipt reuse.
The README-only paired experiment also reduced pytest-selective's elapsed time from 211s to 26s, retaining routing regressions, docs and package validation. The same report records a Due docs-only preservation check at 26s elapsed / 91 runner-seconds; it has no paired control and is not presented as a measured speedup.
CI-esta makes the next optimization visible. In a real pytest-selective report, required jobs completed in 295s. The slowest Windows job took 279s; all jobs totaled 731 runner-seconds. Its separate completed-run reporter used 19s of runner time and was not a validation prerequisite. How this was measured includes the source JSON, run identities and limits.
Start with reporting, then narrow inputs and preserve full checkpoints. For Due and pytest-obligation conformance lanes, review every runtime/configuration input before enabling receipt reuse. A previous green workflow alone is insufficient evidence.
CI-esta now uses the selector too. Its same-checkout README probe used 49 versus 105 runner-seconds (53.3% less) and reached the gate in 45s versus 88s, with quality and package checks preserved. The new evidence report also computes real dependency critical paths and slack for all three consumer adoption runs.
What a reused lane means
declared inputs + actual tool bytes
|
matching receipt?
/ \
fresh passing missing, stale,
lane found failed or uncertain
| |
reuse evidence execute lane
\ /
strict aggregate gate
Receipts are recorded only after required work passes. Explicit reruns execute again. Missing or contradictory evidence must not silently green the merge gate. Input declarations remain your responsibility: a changed external service cannot be inferred from an unchanged Git tree.
Documentation
| Goal | Read |
|---|---|
| Find slow jobs and estimate runner costs | GitHub Actions observability |
| Diagnose slow Python CI without cutting checks | Python CI tuning |
| Combine caches, selection, timing and parallelism | CI optimization guide |
| Learn file costs and balance complete inventories | Timing feedback tutorial |
| Track what was upstreamed and adopted | Closure ledger |
| Find the actual dependency path and slack | Critical-path analysis |
| Restore and repair complete Python environments | Environment cache |
| Check what is actually upstream and adopted | Revision-bound adoption audit |
| Avoid repeating proven work | Evidence reuse |
| Report TypeScript or other non-Python work | Language-neutral reporting |
| Integrate selection and conformance tests | Project integrations |
| Compare CI optimization approaches | Alternatives |
| Understand extraction scope and migration | Upstreaming |
| Run tests and contribute | Contributing |
Install the Python tools
pip install "ci-esta>=0.1.0,<0.2.0"
ci-esta --help
Actions and reusable workflows use the compatible @v0.1 release tag. Python
lockfiles retain exact resolved versions and artifact hashes.
Status and limits
Extracted from Gigaverse's backend-common CI tools. APIs and schemas may evolve before 1.0. On the current Git revision, base reporting installs neither pytest nor pytest-selective (the published 0.1.0 release predates this split). Install ci-esta[selection] for Python selection reports or ci-esta[pytest] for pytest execution tools. Python 3.11+ is required for the CLI; Actions do not require your application to use Python.
Cost figures are estimates using configured rates, not billing records. Admission delay includes more than runner queue time. Evidence reuse is bounded by declared inputs, proof freshness and GitHub API visibility. No universal speedup is claimed. The backend-common compatibility migration is tracked separately from publication; see adoption.
Apache-2.0. See source provenance.
CI toolkit catalog
CI-esta consolidates reusable CI execution, measurement and evidence tooling. Selection and test-isolation guards live in pytest-selective; durable-work conformance tests live in pytest-obligation; the Django/PostgreSQL/Celery application runtime lives in Due.
| Area | Tools | Python / pytest dependency |
|---|---|---|
| GitHub Actions evidence | Independent lane receipts, incremental PR bases, inventory reuse, validation gates, stale-run cancellation | No pytest required |
| Reporting | Run latency, critical dependencies, all-attempt runner cost, sticky summaries, Prometheus snapshots | Python CLI; accepts non-Python workflows |
| Test execution | JUnit aggregation, duration merge, coverage floors, prior-failure canaries, local shard supervisor, completion receipts | pytest adapters; JUnit and coverage readers are reusable |
| Selection integration | Cached impact planning, shard sizing, type-check scope | Calls pytest-selective; no copied selector |
| Test hygiene | Import boundaries; compatibility delegates for pytest-selective's isolation and expansion guards | Python source analysis |
| Security and CI lint | Semgrep, Trivy, actionlint, shellcheck, changed diagnostic filtering | Any GitHub repository; scanner prerequisites apply |
| Container evidence | OCI layer comparison, pull experiments, frozen runtime observers, Kubernetes node probes, ECR manifest reuse | Python orchestration; Docker/AWS/Kubernetes providers |
| Live CI drills | Repeated-head, retag, main-moved and readiness scenarios with leased disposable PR slots | Existing Gigaverse consumer profiles; requires explicit live credentials |
See the action catalog, migration inventory and preservation test plan. Some actions retain the originating project's defaults (Python 3.14, coverage schedule, security labels); review their documented inputs. The optional dependency-token receipt adapter recognizes backend-common pins. Without that adapter, evidence uses exact dependency pins.
The wheel includes action support resources. ci_esta.resources.source_root() locates them for compatibility imports; normal Actions users can use compatible GitHub uses: tags such as @v0.1. Install ci-esta[pytest] when loading ci_esta.testing.pytest_completion as a pytest plugin.
Runner sizing, distributed shard pools and opt-in resource/pytest hang diagnostics: runner recipes. Standard import rules use import-linter; filesystem-specific rules remain in the shared boundary checker.
Metadata
Release files for ci-esta 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| ci_esta-0.2.1.tar.gz | 798.1 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| ci_esta-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.1 MB
Release files / ci_esta-0.2.1.tar.gz
| Download URL | ci_esta-0.2.1.tar.gz |
|---|---|
| Size | 798.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
9e2c7fecd719e213b4d03e14e910858d08d7cb8cc8a2afac56daf79a7a52dfed
|
|
BLAKE2b-256 checksum How to use checksums |
5c9b93ba852facd67b6321b08eb07adf593d32b718ed69af1af0e5356331468d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 23, 2026.
Transparency logRelease files / ci_esta-0.2.1-py3-none-any.whl
| Download URL | ci_esta-0.2.1-py3-none-any.whl |
|---|---|
| Size | 253.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e0e578f9e5a2f83b5e3a302e1b9c6dd526ac51da6ee9a922a823f4a03da371a0
|
|
BLAKE2b-256 checksum How to use checksums |
ca6019038768a09554d160c0d4044d3112c2c974468b9c4c22fa9c3d46723adc
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 23, 2026.
Transparency logSecurity for ci-esta 0.2.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for ci_esta-0.2.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 23, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.