Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Content-addressed target caching with declared inputs and outputs

Đang mở
  • Có gì không ổn?
#647 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, github-actions
Lĩnh vực
build-system, ci-cd

Hướng nghiên cứu

Bắt đầu bằng cách đọc global.json và .github/workflows/build.yml, sau đó kiểm tra cách Fallout hiện đang sử dụng .fallout/temp. Lập bản đồ luồng thực thi mục tiêu và luồng tham số trước khi chọn ranh giới bộ nhớ đệm. Công việc được xem là hoàn tất khi đáp ứng các tiêu chí chấp nhận, bao gồm bộ nhớ đệm cục bộ an toàn, bypass và verification opt-in, cùng định hướng staged pluggable-store.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
169
Fork
21
Merge trung bình
3 ngày 7 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Fallout-build/Fallout

Tất cả issue của Fallout-build/Fallout

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.