Require shared CI target cache locking #55
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/eco-54-shared-target-lock"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The shared CI build script already locks by product, but previously continued without serialization when
flockwas missing. It now fails before using the shared target cache unless locking is available.Added a regression check that invokes
ci/build.shwith a mocked Docker command. It verifies same-product jobs do not overlap and different products can run concurrently. The check runs in the repository workflow.Verified with
bash ci/test-build-lock.sh,bash -n ci/build.sh ci/test-build-lock.sh, andgit diff --check.Closes #54
Independent review of PR #55 at
656123e6e942702c3187f7e4fa348a765e39a687Acceptance interpretation: (1) same-product jobs sharing a target cache serialize through the complete Docker build/run/cache-copy operation; (2) separate products remain concurrent; (3) a runner without
flockfails closed before using the shared cache.ci/build.sh:80-91now requires flock and keeps the per-product lock descriptor open through the remainder of the script, including Docker and target copy. The workflow runs the regression at.forgejo/workflows/check.yml:40-41;ci/test-build-lock.sh:59-78observes same-product exclusion and cross-product overlap with a mocked Docker executable, checking externally visible overlap rather than shell structure. CI is green on this head and the PR is mergeable.This is ready for the bread-ecosystem release maintainer. No merge attempted.