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

Content-addressed target caching with declared inputs and outputs

Aperta
  • Qualcosa non va?
#647 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, github-actions
Ambito
build-system, ci-cd

Direzione di ricerca

Inizia leggendo global.json e .github/workflows/build.yml, quindi esamina come Fallout usa attualmente .fallout/temp. Mappa il flusso di esecuzione target e dei parametri prima di scegliere i confini della cache. Il lavoro è completo quando i criteri di accettazione sono soddisfatti, inclusi il caching locale sicuro, il bypass e la verifica opt-in e la direzione staged pluggable-store.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement target/backlog
Problem

Fallout re-runs every target in the execution plan on every invocation. There is no target-level cache. MSBuild's own incremental build is timestamp-based, works only inside one workspace, and does not survive a fresh CI runner. Gradle, Bazel and Nx all cache at this level; NUKE never did.

A full rebuild on every iteration is the main limit on how many edit-build-check cycles fit into a working session. That applies to a person at a keyboard and to an automated caller equally.

Outcome

A target declares its inputs and outputs. Fallout hashes the inputs, and when the hash matches a stored entry it restores the outputs and skips the target.

Acceptance criteria
  • Targets can declare input and output sets; a target that declares neither is never cached
  • Input hashing uses file content, never modification time
  • The cache key includes the .NET SDK version from global.json, the configuration, the target framework or RID, the Fallout version, and every parameter the target reads
  • A cache hit restores the declared outputs and reports the target as skipped, with the reason
  • --no-cache bypasses the cache entirely
  • A verify mode runs a target both cached and uncached and reports any difference in the outputs
  • The cache store sits behind an interface, with a local filesystem implementation first
Making it work on CI, and on GitHub Actions in particular

This has to survive ephemeral runners, which is where most of the design risk sits.

  • Absolute paths, timestamps and machine identity all differ between runs. Hash content, keep paths relative inside the cache key, and require deterministic build settings (ContinuousIntegrationBuild, Deterministic, PathMap) so outputs can move between machines.
  • actions/cache stores one immutable archive per key and cannot update an existing key. A first pass can restore by key prefix and save under a new key at the end of the job. Fallout's workflows already cache .fallout/temp, so a cache directory there needs no new workflow step.
  • Entry-level caching needs the runner's cache service API (ACTIONS_RESULTS_URL and ACTIONS_RUNTIME_TOKEN), which supports per-entry read and write. This is how sccache, Gradle and Turborepo do remote caching on GitHub Actions. It is the argument for a pluggable cache store rather than a hard dependency on actions/cache.
  • The cache limit is 10 GB per repository, evicted least-recently-used. Per-entry eviction starts to matter once build outputs are stored.
  • Pull requests from forks receive a read-only cache token, so an untrusted pull request cannot write cache entries.
  • Adjacent and independent of this work: the cache key in .github/workflows/build.yml has no restore-keys, so editing any .csproj discards the whole NuGet package cache.
Notes

A wrong cache hit is worse than no cache, so caching stays opt-in per target until the key provably covers everything that affects output. Suggested order: local hashing and cache first, pluggable store second, GitHub Actions cache-service backend third.

Lingua principale
C#
Stelle
169
Fork
21
Merge medio
4g 5m
PR unite (30g)
16

Preparare l'ambiente

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 Fallout-build/Fallout

Tutte le issue di Fallout-build/Fallout

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.