Skip to content

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

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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