Configuring for c-code

[icemac]

Created using zopefoundation/meta#416

[icemac]

@dataflake It seems we still have cache poisoning in Windows PyPy: I deleted the cache to get #127 green and merged. (I will not start working on it just now.)

[dataflake]

Observation just now, unsure if this is relevant:

• went to the Caches page and deleted all Windows caches with pypy in the name
• re-ran only the failing actions from https://github.com/zopefoundation/zope.security/actions/runs/25152545156
• refreshed the Caches page and the caches with pypy in the name have not been generated. But it shows that the cache from the master branch with key Windows-X64-pip-3.14 was used just a few minutes ago. All others are one or more hours old

[dataflake]

After going through the raw logs I saw instances where the cache GitHub action would match the current environment to a bad key because all those invocations also pass a variable restore-keys with a partial key value. Example:

      - name: pip cache (Windows)
        uses: actions/cache@v5
        if: ${{ startsWith(runner.os, 'Windows') }}
        with:
          path: ${{ steps.pip-cache-windows.outputs.dir }}
          key: ${{ runner.os }}-${{ runner.arch }}-pip-${{ matrix.python-version }}
          restore-keys: |
            ${{ runner.os }}-${{ runner.arch }}-pip-

The restore-keys value is a truncated version of the actual key and from the scant documentation it seems to be a fallback if the actual key value produces no cache hit. This bites us with PyPy because the restore-key value matches cache keys for both CPython and PyPy cache files, I saw the following in the zope.security actions logs:

2026-04-30T10:55:08.1856195Z ##[group]Run actions/cache@v5
2026-04-30T10:55:08.1856483Z with:
2026-04-30T10:55:08.1856708Z   path: c:\users\runneradmin\appdata\local\pip\cache
2026-04-30T10:55:08.1857012Z   key: Windows-X64-pip-pypy-3.11
2026-04-30T10:55:08.1857266Z   restore-keys: Windows-X64-pip-
...
2026-04-30T10:55:08.1862753Z ##[endgroup]
2026-04-30T10:55:08.6373639Z Cache hit for restore-key: Windows-X64-pip-3.14
2026-04-30T10:55:09.3405656Z Received 15224017 of 15224017 (100.0%), 26.2 MBs/sec
2026-04-30T10:55:09.3406958Z Cache Size: ~15 MB (15224017 B)
2026-04-30T10:55:09.3464409Z [command]"C:\Program Files\Git\usr\bin\tar.exe" -xf D:/a/_temp/043ced54-185f-4483-a6fe-7761d4c8f873/cache.tzst -P -C D:/a/zope.security/zope.security --force-local --use-compress-program "zstd -d"
2026-04-30T10:55:10.7805973Z Cache restored successfully
2026-04-30T10:55:10.7938089Z Cache restored from key: Windows-X64-pip-3.14

I do not know if the attempt to provide a fallback cache key provides any value, after removing all instances in 03078a8 things didn't seem to run slower. But the actions run succeeded immediately.

I know this restore-keys setting has existed in our test configurations forever. I bet it was only added because the documentation mentions it - for simple scenarios. Now it bites us. I suggest removing it for the c-code templates in zope.meta.

[davisagli]

I suggest removing it for the c-code templates in zope.meta.

+1. An incorrect cache is worse than no cache.