How to design a workflow that caches objects complied from a submodule?

[blackears]

🏷️ Discussion Type

Question

Body

I'm trying to figure out how to set up a github workflow action so that it caches the complied results of a submodule so that it's not built every single time I submit changes to my main project. I'm not quite sure how the actions/cache rule works.

This is something I modified from a Gemini prompt:

      # Setup caching for faster subsequent builds
      - name: Setup SCons Cache
        uses: actions/cache@v6
        with:
          path: |
            ${{ github.workspace }}/.scons_cache/
            ${{ github.workspace }}/godot-cpp/.scons_cache/
          key: ${{ matrix.platform }}-${{ matrix.arch }}-${{ github.sha }}
          restore-keys: |
            ${{ matrix.platform }}-${{ matrix.arch }}-

      # Build godot-cpp dependencies (Release)
      - name: Build godot-cpp (Release)
        run: |
          scons platform=${{ matrix.platform }} arch=${{ matrix.arch }} target=template_release -C godot-cpp

      # Build custom extension binaries (Release)
      - name: Build Extension (Release)
        run: |
          scons platform=${{ matrix.platform }} arch=${{ matrix.arch }} target=template_release

Right now when the third step runs, it re-compiles the files that were already built in step 2. How could I change this so that it checks to see if the objects that were created in step 2 are up to date, and if so reuses them?

godot-cpp is a third party submodule that is in the godot-cpp directory of my project and which contains hooks for using Godot's API in C++.

Guidelines

• I have read and understood this category's guidelines before making this post.

[mjubayerahmed115-ship-it]

[mjubayerahmed115-ship-it]

I want to take someone to do what it takes to take the message in inbox

[nmloc]

Two separate things are going on, and neither is really about actions/cache.

1. Step 3 rebuilds godot-cpp because it is a different SCons build. SCons decides what is up to date from its signature database (.sconsign.dblite), and that file lives next to the top-level SConstruct (SConsignFile docs). scons -C godot-cpp records its signatures in godot-cpp/.sconsign.dblite; the build from your project root uses ./.sconsign.dblite, which knows nothing about those objects, so it compiles them again. If your SConstruct is based on godot-cpp-template, it also pulls godot-cpp in itself with SConscript("godot-cpp/SConstruct", {"api_version": ..., "customs": ...}), so the flags may not even match your standalone build. Step 2 is redundant: drop it and run one scons from the root.

2. Your cache folders are empty. SCons only writes a build cache when CacheDir() is called. godot-cpp does that only when the SCONS_CACHE environment variable is set (SConstruct#L62-L65). Without it, actions/cache saves and restores empty directories.

This is what the official godot-cpp-template workflow does, adapted to your steps:

      - name: Setup SCons Cache
        uses: actions/cache@v6
        with:
          path: ${{ github.workspace }}/.scons_cache/
          key: ${{ matrix.platform }}-${{ matrix.arch }}-release-${{ github.sha }}
          restore-keys: |
            ${{ matrix.platform }}-${{ matrix.arch }}-release-

      - name: Build Extension (Release)
        env:
          SCONS_CACHE: ${{ github.workspace }}/.scons_cache/
        run: |
          scons platform=${{ matrix.platform }} arch=${{ matrix.arch }} target=template_release

On the first run everything compiles and lands in .scons_cache/. On later runs the cache is restored from the newest entry that matches the restore key, and SCons copies each unchanged godot-cpp object out of it ("Retrieved ... from cache" in the log) instead of compiling it. Only your own changed sources compile.

If you also build template_debug, keep it in a separate cache key (as the template does with target-type in its cache name), otherwise a release run can restore a cache that a debug run filled and get almost no hits.