Restructure CI into tiers for 1.0 and close lint, coverage and dependency-automation gaps

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

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github-actions, go, rust
領域
build-system, ci-cd, testing-qa, tooling

調査の方向性

Start with the existing workflows named in the issue and docs/CI.md, then inspect tests/ci/test_workflow_concurrency.py and prototypes/structural/driver/main_test.go. Map the current jobs against the proposed Fast, Full, Deep, Breadth and Release tiers, including the listed Go, Rust and dependency checks. Done means the tiers, documentation, coverage artifact, fork-aware dependency automation, SHA-pinning check and schedule prohibition satisfy the acceptance checklist.

索引モデルが issue の本文から書いたものです。

説明

enhancement follow-up

Current state (2026-09-22)

The workflows are ci.yml, structural-worker.yml, structural-prototype.yml and release-candidate.yml. Draft PRs run only a lightweight preflight. Ready PRs and main run the full set: vet, race tests and govulncheck (Linux only) on Linux/macOS/Windows; Linguist and scc conformance; and the structural worker on 5 platforms.

That design was shaped by private-repository minute costs, estimated in docs/CI.md at ~$2.26 per full cycle, with macOS runners 10× the Linux rate. Once the repository is public, standard GitHub-hosted runners and self-hosted runners are free and unlimited (docs). The constraint goes away, but the structure should be ready. Even then, deep tiers stay on-demand until the owner decides otherwise (see Scheduling policy).

Gaps

  • No deep on-demand jobs: fuzzing campaigns, full-corpus oracles, benchmarks, mutation testing, upstream-drift checks.
  • No coverage reporting. Measured first-party statement coverage is 82.6%, and nobody sees it.
  • Linting is go vet only: no staticcheck or golangci-lint config.
  • No cargo clippy or rustfmt for the worker.
  • No Dependabot or Renovate for the Go modules, the Cargo workspace or Actions. Actions are already pinned to full commit SHAs with version comments; keep that and verify it automatically. Dependency automation must respect the maintained Enry/go-git forks: their updates go through canonical regeneration and provenance checks, not plain version bumps.
  • govulncheck runs on Linux only.
  • No linux-arm64 in the core test matrix.
  • Ergonomics regression tests (tests/ergonomics_v100/audit/regression_tests) and the npm registry conformance check aren't in CI.
  • No fuzzing, performance or oracle jobs (#87, #90, #84).
  • A time.Sleep(time.Minute) in prototypes/structural/driver/main_test.go.

Proposal: tiers

Tier Trigger Contents
Fast every push/PR, including drafts build, unit and race tests (Linux), lint, clippy, deterministic cost-counter and allocation gates, Linguist conformance subset, metamorphic tests on generated trees
Full ready PR and main all platforms including linux-arm64; full conformance; oracle subset; coverage report with per-package floors and diff coverage; ergonomics regression tests
Deep (on demand) workflow_dispatch only; also run by the release workflow fuzz campaign; oracle harness on the golden corpus; macro-benchmarks on a stable runner when one exists; govulncheck/cargo-audit on all OSes
Breadth and drift (on demand) workflow_dispatch only; also run by the release workflow full golden corpus on Linux/macOS/Windows; mutation testing; upstream drift: new Linguist, Enry, scc, BCA, Syft or Noir releases are run through the differential harness and an issue is opened with the diff
Release dispatch everything above at the release commit, plus the release-tier benchmark report and the artifact hardening in #13

Scheduling policy

All CI stays event-driven: push, pull_request and workflow_dispatch (the release workflow is dispatch-driven too). No workflow has a schedule: trigger until the owner explicitly enables scheduled work, planned for well after the repository is public, for cost-efficiency.

The deep workflows are still built now, runnable by hand and through local make targets, so that enabling a schedule later is a small, reviewed change.

Acceptance

  • The tiers implemented, with job-level documentation in docs/CI.md of what each tier guarantees.
  • Lint configs (golangci-lint with staticcheck; clippy with -D warnings), fork-aware Dependabot or Renovate, and an automated check that Actions stay SHA-pinned.
  • Coverage published per package as a workflow artifact, with no third-party service required. The floor starts at today's numbers and must not regress.
  • No schedule: triggers anywhere, enforced by a CI contract test (e.g. alongside tests/ci/test_workflow_concurrency.py). Deep tiers run only via workflow_dispatch or the release workflow. Enabling schedules is a separate owner decision, well after the public flip.

Part of the 1.0 quality program: #83. Epic: #81.

主要言語
Go
スター
0
フォーク
0
平均マージ
11時間 3分
マージ済み PR（30日）
5

環境構築

はじめの一歩

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

war-and-code/dircue のほかの issue

war-and-code/dircue の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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