Fix Docker build cache command handling

[TorstenDittmann]

Summary

• keep Docker builds running the original user command when build cache is enabled
• remove generated cache command script usage from the Docker executor
• keep cache artifact restore/upload best-effort and preserve cache warnings in build output
• add unit coverage for avoiding cache wrapper/lifecycle command generation

Tests

• ./vendor/bin/phpunit --configuration phpunit.xml --testsuite=unit --filter DockerTest
• ./vendor/bin/pint --test --config pint.json src/Executor/Runner/Docker.php tests/unit/Executor/Runner/DockerTest.php

[greptile-apps]

Greptile Summary

This PR refactors the Docker executor's build-cache path so that the runtime image's own build helper (helpers/build.sh) owns cache detection and messaging, while the executor focuses solely on sqfs artifact restore/store around the original user command. The prepareBuildCacheScripts method and the build-cache.sh wrapper invocation are removed, replaced by getBuildCommands, validateBuildCacheKey, and best-effort try-catch blocks around restore/store with $cacheWarnings collected and correctly merged into both success and failure output paths.

• validateBuildCacheKey is called outside the restore try-catch, so invalid keys still propagate as 400 errors rather than being silently swallowed.
• $cacheWarnings is initialized before the outer try block and merged in the outer catch (lines 492–494), preserving restore-failure warnings even when the build command itself also fails.
• The e2e assertions are updated to match the new strings emitted by the runtime image's helpers/build.sh (Build cache saved. / Build cache hit.), creating an implicit dependency on a corresponding runtime image update.

Confidence Score: 4/5

Safe to merge with awareness that cache-enabled builds now embed the original user command directly into the script --command "..." and sh -c wrappers, which changes shell-parsing behavior relative to the old script-file approach for that code path.

The restructuring is architecturally sound — validateBuildCacheKey correctly sits outside the best-effort try-catch, $cacheWarnings is initialised before the outer try and merged in the catch so restore warnings survive a build failure, and getBuildCommands consolidates what was previously duplicated inline. The main open concern is that cache-enabled builds now splice the raw user command into the shell logging wrappers (both v5's script --command "..." and v2's sh -c subshell), whereas before the command was written to a script file and executed directly, so shell metacharacters in the build command are now interpreted by an additional shell layer only on the cache-enabled path.

src/Executor/Runner/Docker.php — specifically the getBuildCommands output when cacheEnabled is true and the user command contains shell metacharacters beyond double quotes.

Important Files Changed

Filename	Overview
src/Executor/Runner/Docker.php	Core change: removes the build-cache wrapper script and prepareBuildCacheScripts; introduces getBuildCommands, validateBuildCacheKey, and getBuildCacheWarning; wraps restore/store in best-effort try-catch; merges $cacheWarnings in both success and failure paths. Cache detection/messaging is now delegated to the runtime image's own build helper (e.g. helpers/build.sh).
tests/unit/Executor/Runner/DockerTest.php	New unit test suite covering getBuildCommands (via reflection) and validateBuildCacheKey; confirms original user command is preserved and old cache wrapper scripts are absent. Tests are well-structured and use reflection correctly for private method access.
tests/e2e/ExecutorTest.php	Updates cache hit/save assertion strings from [build cache] Saved./[build cache] Hit. to Build cache saved./Build cache hit. to match the output now emitted by the runtime image's own helpers/build.sh script rather than the executor's wrapper.

_{Reviews (4): Last reviewed commit: "fix: validate build cache keys" | Re-trigger Greptile}

[greptile-apps]

Cache lifecycle skipped

When cacheKey is set, this path now runs the original user command directly and then tries to upload /cache/stores.sqfs. The removed wrapper was the code path that ran the build-cache helper around the command, and the removed script generation was the code path that gave that helper the original build command. Normal build commands such as tar -zxf ... && bash helpers/build.sh "npm install..." do not create /cache/stores.sqfs, so storeBuildCacheArtifact() returns early and no cache artifact is saved. Cache-enabled builds can still succeed, but subsequent builds will not produce the expected saved/hit cache behavior.

Artifacts

Repro: PHP script testing getBuildCommands cache lifecycle gap

• Contains supporting evidence from the run (text/x-php; charset=utf-8).

Repro: failing test output showing no cache lifecycle in build commands

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}