Skip to content

daemon/setup: expose zccache store location so consumer workflows can actions/cache it #149

@zackees

Description

@zackees

Problem

fbuild's setup composite action installs and configures zccache as the per-TU object cache for Rust builds (and via wrap_args, potentially for compiler invocations). Where zccache persists its object store (~/.zccache/, $ZCCACHE_DIR, or configured override) is not a documented output of the action, so consumer workflows (bench/fastled-examples, FastLED CI) don't know what path to feed actions/cache.

Iter3 of the #112 benchmark confirmed this is load-bearing: 65 MB of .build/pio/uno/.fbuild/ was cached and restored, but cross-run per-TU reuse was zero. Even once #146 + #148 (absolute paths) land, zccache's store is the directory that actually holds compiled .o files — if it's not cached, every cross-run compile re-runs the compiler.

Sub-task of #147.

Fix direction

  1. The setup composite action emits a step output zccache-store-path and sets ZCCACHE_DIR in $GITHUB_ENV (so downstream workflows can reference it in actions/cache's path: block).
  2. The action README / fbuild docs include a canonical cache block:
- name: Setup fbuild
  id: fbuild-setup
  uses: fastled/fbuild/.github/actions/setup@main

- uses: actions/cache@v4
  with:
    path: |
      ~/.fbuild
      \${{ steps.fbuild-setup.outputs.zccache-store-path }}
      <project>/.build/pio/<board>
    key: fbuild-v1-\${{ runner.os }}-\${{ runner.arch }}-\${{ hashFiles('...') }}

Out of scope

Definition of done

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority: p1Important follow-up after p0 foundations

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions