godofecht / godofecht/azazel

Production blocker: prove complete cache input closure before ungating

Open
#46 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1
Forks
0
Avg merge
8m
Merged PRs (30d)
1

Description

Problem

The shared cache can restore zig-out and skip compilation, so a false cache hit is a correctness failure. The current key is useful as a prototype but does not yet prove that every artifact-affecting input participates in the key.

PR #43 therefore gates cache_build.sh behind AZAZEL_EXPERIMENTAL_CACHE=1 and removes the stale-hit impossibility claim.

Required coverage

The production cache key needs an explicit declared-input closure covering at least local Zig/C/C++ sources and headers, object files, generated tool inputs/outputs, local path dependencies, package identities and relevant package build arguments, target/cpu/ABI, optimization/build options, Azazel executor/generator version, toolchain identity, and external/system dependencies or a deliberate policy that makes them ineligible for shared caching.

Arbitrary pre/post commands and environment-dependent generators need either declared inputs/environment or a hard refusal from the production cache path.

Acceptance criteria

  • Mutation tests show that changing every modeled artifact input changes the key.
  • Target and build-option changes produce different keys.
  • Local path dependency content changes produce different keys.
  • Native source/header changes produce different keys.
  • Builds with undeclared side effects/inputs are rejected or explicitly marked non-cacheable.
  • Cache-hit artifacts are compared against clean-build artifacts across representative real-project parity slices.
  • Only after those tests pass is the AZAZEL_EXPERIMENTAL_CACHE=1 gate removed.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with cache_build.sh and the changes described for PR #43, including the AZAZEL_EXPERIMENTAL_CACHE=1 gate. Map the declared cache inputs against the required coverage, then add mutation and clean-build parity tests. Done means modeled input changes alter the key, undeclared side effects are rejected or non-cacheable, and the gate is removed only after the acceptance criteria pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, cpp, shell, zig
Domain
build-system, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.